request 和 current_app 不能在函数外直接使用，因为它们是依赖线程/协程隔离栈的 localproxy 代理对象，脱离请求或应用上下文会抛出 runtimeerror。
request 和 current_app 为什么不能在函数外直接用
因为它们不是真正的全局变量，而是 LocalProxy 代理对象，背后依赖线程/协程隔离的栈（_req_ctx_stack 和 _app_ctx_stack）。一旦脱离上下文环境——比如在模块顶层、后台线程、或 CLI 命令未手动推送时调用 request.form 或 current_app.config——就会抛出 RuntimeError: Working outside of request context 或 Working outside of application context。
常见错误现象：
- 在
if __name__ == '__main__':下直接 print(request) - 在单元测试 setup 中访问
session却没进test_client请求流 - 用
threading.Thread启动任务后，在子线程里调用g.db
什么时候必须手动 push 上下文
Flask 自动管理上下文只发生在 WSGI 请求入口（如 app.wsgi_app）和 CLI 命令执行时。其余场景需显式推送：
inference.sh 的 Python SDK：运行 AI 应用、构建智能体，并集成 150 多个模型。包名：inferencesh (pip install inferencesh)。支持同步/异步……
- 命令行脚本（非
flask run启动的独立 Python 文件）：用with app.app_context(): - 异步任务（Celery、APScheduler）中需要读配置或查数据库：先
app.app_context().__enter__()或用with app.app_context(): - 单元测试中模拟请求之外的操作：比如预热缓存、初始化扩展，用
app.app_context()；若还需request数据，则改用app.test_request_context() - 注意：
app.test_request_context()会同时推送应用 + 请求上下文，但不会触发before_request钩子
g 对象和 session 的生命周期差异
g 是应用上下文绑定的临时容器，只在当前 app_context 生命周期内有效；session 是请求上下文绑定的会话存储，随每次请求新建/销毁，且默认加密签名后写入 Cookie。
-
g适合放“本次应用上下文内一次计算、多次复用”的数据，比如g.user = load_user(id)，避免视图函数里重复查库 -
session适合跨请求保持状态，比如登录态session['user_id'] = 123，但它不保证服务端持久化（除非换用 Redis session 后端） - 误把
g当成跨请求缓存：比如在定时任务里设g.cache = {...}，下次请求进来时该值已丢失 - 误在非请求上下文中读
session：即使有app_context，没req_context也拿不到session
多应用共存时 current_app 的指向逻辑
当你在一个进程里运行多个 Flask 实例（例如 API 服务 + 管理后台），current_app 不是静态绑定的，而是由当前栈顶的应用上下文决定。
- 每个
app.app_context()推送时，会把对应app实例压入_app_ctx_stack，current_app就取这个栈顶的.app - 如果两个应用共享一个扩展（如 Flask-SQLAlchemy），必须确保每个应用初始化时传入自己的
app，否则db.init_app(app)只绑定到最后一个被init_app的那个 - 调试技巧：打印
id(current_app._get_current_object())可确认当前指向哪个实例 - 容易踩的坑：在工厂函数外定义全局
db = SQLAlchemy()，却在多个create_app()调用中反复db.init_app(app)，导致current_app指向混乱
真正难的不是记住哪些对象属于哪个上下文，而是意识到：上下文不是“自动生效的魔法”，而是一套明确的栈操作协议。任何脱离 push/pop 流程的地方，request、current_app、g、session 全部失效——哪怕它们看起来像全局变量。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
