request对象是上下文局部代理，仅在请求上下文中存在；脱离上下文（如视图外、后台线程）访问会报“working outside of request context”错误，因其依赖线程/协程的上下文栈，栈空则查找失败。
request 对象不是全局变量，也不是线程安全的“单例”，它只在请求上下文（RequestContext）被推入时才存在。一旦上下文弹出，访问 request 就会抛出 RuntimeError: Working outside of request context。
这直接导致它“表现不同”——不是对象本身变了，而是它根本**有时不存在**。
为什么在视图函数外访问 request 会报错？
因为 request 是一个上下文局部代理（LocalProxy），背后绑定的是当前线程/协程的请求上下文栈。没有请求进来时，栈为空，代理找不到目标。
- 常见错误现象：
RuntimeError: Working outside of request context - 典型误用场景：在模块顶层、定时任务、后台线程、或
app.run()之后直接调用request.args或request.json - 不能靠 try/except 捕获来“兜底”，而应主动判断上下文是否存在：
from flask import has_request_context; if has_request_context(): ... - Flask 2.3+ 支持
flask.globals.request的 lazy lookup，但不改变生命周期本质——没上下文，查不到就是查不到
为什么在 before_request / after_request 中能用，teardown_request 中却可能失效？
teardown_request 确实能访问 request，但前提是它**尚未被弹出**；而 teardown_request 的执行时机紧挨着上下文弹出前，此时 request 还“活着”，但已不可用于生成新响应（比如不能再调用 request.get_json()，因为底层 environ 的输入流已被读取并关闭）。
- 容易踩的坑：
request.json在teardown_request中首次访问会失败，报BadRequest: Failed to decode JSON object或ValueError: I/O operation on closed file - 原因：JSON 解析依赖
request.get_data()，而该方法在视图函数返回后、after_request执行前就已完成读取；teardown_request阶段输入流已关闭 - 正确做法：需要 JSON 数据时，务必在
before_request或视图函数内提前解析并存入g，例如：g.parsed_json = request.get_json() or {}
为什么多线程/异步任务里 request 总是 None？
上下文是线程/协程局部的，子线程或新事件循环中没有自动继承父请求的上下文。哪怕你把 request 对象传进去，它也会立刻失效——因为它内部绑定的是原线程的上下文栈。
- 常见错误现象：用
threading.Thread或asyncio.create_task处理耗时逻辑，并试图在其中读request.args，结果得到None或报错 - 解决路径只有两条：要么把所需数据（如
request.args.to_dict()、request.headers.get('X-User-ID')）提前提取出来传入子任务；要么手动推送上下文（极不推荐，易泄漏）：with app.app_context(): with app.request_context(environ): ... - 注意：
app.request_context()需要完整的 WSGIenviron字典，不是简单复制request属性就能模拟的
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
