Flask 的 request 在后台线程中不可用，因其依赖线程局部的请求上下文；需手动提取数据传入子线程，或使用 copy_current_request_context；app_context 适用于无请求场景，request_context 才支持 request/g/session。
Flask 的 request 为什么在后台线程里拿不到
因为 request 不是全局变量，它只在请求生命周期内、且仅在处理该请求的线程中有效。一旦离开视图函数或跳到新线程（比如用 threading.Thread 或 concurrent.futures），request 就会报 RuntimeError: Working outside of request context。
这不是 Flask 故意设障，而是靠 LocalStack 实现的线程局部存储——每个线程有自己独立的上下文栈，主线程的请求信息不会自动透传。
- 别在子线程里直接读
request.args、request.json等，它们会炸 - 真需要传递数据，就手动提取：比如把
request.get_json()的结果作为参数传进线程函数 - 如果要用
g，同样不能跨线程访问；它和request一样绑定在当前请求线程的RequestContext上
应用上下文 app_context() 和请求上下文 request_context() 到底该用哪个
简单说：request_context() 是为 HTTP 请求准备的，带 request、session、g；app_context() 只提供 current_app 和 g（但此时 g 和请求无关），适合命令行脚本、定时任务、Shell 调试等没有真实请求的场景。
常见误用：在 Celery 任务或后台线程里调 app_context() 想“模拟”出 request——没用，request 还是 None。
立即学习“Python免费学习笔记（深入）”；
- 有真实 HTTP 请求（比如用户发了个 POST）→ 必须用
request_context() - 只是想跑个数据库查询或发邮件，不依赖用户输入 →
app_context()就够了 - 两者可以嵌套：先
app_context()，再request_context()，但反过来不行
LocalStack 堆栈怎么管理多个上下文——不是靠全局变量，是靠 threading.local
Flask 底层的 LocalStack 本质是对 threading.local 的封装，每个线程独享一个 _local 实例，里面存着自己的栈（_local.stack）。push 时压栈，pop 时出栈，完全隔离。
所以你在主线程 push 一个 RequestContext，子线程里查 _local.stack 是空的——它根本没被 push 过。
- 不要试图通过修改
_local来“共享”上下文，这破坏设计契约，后续行为不可预测 -
copy_current_request_context是唯一正经的透传方式，但它只复制数据，不复制整个上下文对象 - 异步场景（如
async/await）更麻烦：Python 3.7+ 的contextvars才是解法，Flask 2.3+ 开始逐步迁移，但老版本仍依赖线程局部
调试时 RuntimeError: Working outside of application context 怎么快速定位
这个错说明你调了 current_app、url_for、render_template 这类依赖应用上下文的东西，但当前线程没激活任何 AppContext。
最常踩坑的位置：单元测试 setup、CLI 命令、信号回调（如 SQLAlchemy after_insert）、或者忘了在脚本开头加 with app.app_context():。
- 检查调用栈最顶上是不是来自
flask.cli或测试 runner，这些地方默认不带上下文 - 用
hasattr(flask.g, '_app_ctx_stack')或flask._app_ctx_stack.top is not None（不推荐，仅供调试）确认上下文是否存在 - 在 Shell 里调试？先执行
app.app_context().push()，再试其他操作
