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 类做了两件事：

• 用自定义 get_ident() 函数生成唯一标识：在纯线程环境返回 threading.get_ident()，在协程环境则拼接线程 ID + 协程 ID
• 内部用字典 __storage__ 存储各标识对应的数据副本，确保每个协程也拥有独立上下文

所以即使你用 async def 视图，只要服务器（如 Uvicorn）正确传播了上下文，request 依然能定位到“当前协程”的请求数据。

request 线程安全 ≠ request 可以随便跨上下文用

线程安全只保证“多个并发请求之间不互相污染”，但不意味着你能脱离请求生命周期随意使用它。常见翻车点：

• 在 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。

Secure Python Code Sandbox

安全 Python 代码沙箱：在隔离的沙箱中执行任意 Python 代码，预装 requests、NumPy、pandas 库。返回 stdout、stderr。

下载

异步视图里 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 就立刻退化成普通空壳——这时候不是它不安全，而是它根本“不在场”。

Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！