request是LocalProxy代理对象，动态查找LocalStack栈顶的当前请求上下文，确保线程/协程间隔离；非全局变量，不可跨上下文使用。
request 对象不是“全局变量”，而是 LocalProxy 代理
很多人误以为 request 是普通全局变量，其实它是一个 LocalProxy 实例，底层指向 werkzeug.local.LocalStack 栈顶的当前请求上下文。每次新请求进来，Flask 会为该线程（或协程）推入一个独立的 RequestContext，request 就是这个栈顶对象的代理。
关键点在于：LocalProxy 不保存数据，只做“动态查找”——每次访问 request.method，它都会调用 local.get_current_object() 去当前线程专属的栈里取值。不同线程查到的是各自栈里的东西，自然互不干扰。
threading.local 不够用，Werkzeug 用 get_ident 做更细粒度隔离
Python 原生的 threading.local 只按线程 ID 隔离，但在协程场景（如 asyncio + Uvicorn）下，一个线程可能跑多个协程，threading.local 就会失效。
Werkzeug 的 Local 类做了两件事：
立即学习“Python免费学习笔记（深入）”；
- 用自定义
get_ident()函数生成唯一标识：在纯线程环境返回threading.get_ident()，在协程环境则拼接线程 ID + 协程 ID - 内部用字典
__storage__存储各标识对应的数据副本，确保每个协程也拥有独立上下文
所以即使你用 async def 视图，只要服务器（如 Uvicorn）正确传播了上下文，request 依然能定位到“当前协程”的请求数据。
request 线程安全 ≠ request 可以随便跨上下文用
线程安全只保证“多个并发请求之间不互相污染”，但不意味着你能脱离请求生命周期随意使用它。常见翻车点：
安全 Python 代码沙箱：在隔离的沙箱中执行任意 Python 代码，预装 requests、NumPy、pandas 库。返回 stdout、stderr。
- 在
threading.Thread子线程里直接访问request.args→ 报RuntimeError: Working outside of application context - 把
request保存成类属性或模块级变量（如cached_req = request）→ 下次请求时该变量仍指向旧上下文，数据错乱 - 在
before_first_request或命令行脚本中 import 后就调用request.url→ 此时根本没请求，LocalStack栈为空
真正安全的用法只有一种：只在视图函数、@before_request、@after_request 这些明确处于请求上下文中的位置使用 request。
异步视图里 request.json 为什么报错，而 request.get_json() 不报
request.json 是同步属性，内部调用 get_data(cache=True) 并立即解析 JSON。但它依赖“请求体已完整加载并缓存”这一前提——这在 async 场景下不成立，因为请求体可能是流式接收的。
request.get_json() 是真正的异步方法（返回 Awaitable），它会等待 IO 完成、加载完整 body、再解析，且全程在当前协程上下文中执行，不会触发上下文切换导致的 LocalStack 查找失败。
所以你在 async def 里必须写：
body = await request.get_json()
而不是：
body = request.json # 可能为 None 或抛 RuntimeError
本质不是 JSON 解析逻辑不同，而是同步/异步上下文绑定时机的差异。
最易被忽略的一点：线程安全机制只在 Flask 自动管理的上下文里生效。一旦你手动开线程、启后台任务、写 CLI 命令，或者用错了 ASGI 中间件，request 就立刻退化成普通空壳——这时候不是它不安全，而是它根本“不在场”。
