Variables locales de contexte et sécurité des threads

How does one global request object stay correct when many visitors hit your app at once? The answer is context locals.

Objects like request and g look like plain globals you import once. But they are special proxies, not ordinary shared variables.

A proxy forwards every access to the real object for the current context. Each request sees its own data through the same import.

Flask calls these context locals. They behave like thread locals but key off the active context, so concurrent requests never collide.

Two threads handling two requests each get their own bound context. So request in one thread never shows another thread's data.

Modern Flask uses contextvars, so isolation holds even for greenlets and async tasks, not just operating system threads.

This is why a single import at the top of your file is safe. The proxy resolves to a different real object for every request.

Spawn a raw thread from a view and it has no context. Accessing request there fails unless you push a context yourself.

Hand a background worker the actual value it needs, like a user id, instead of the request proxy, which will be gone by then.

Need the underlying object behind a proxy? Use _get_current_object, but reach for it rarely and only when you truly must.

Context locals are why Flask feels simple: you import request once and trust it, while the framework quietly keeps every request isolated.

Let us confirm how proxies stay safe.

Flask's globals are really context-local proxies. They resolve per request, keeping threads and async tasks isolated, so one import stays safe everywhere. 🎉