g是线程/协程局部存储对象，生命周期严格绑定单个请求，非全局变量，不可跨请求共享；底层基于werkzeug.local.local实现隔离，请求结束即清空。
g对象的本质是线程/协程局部存储，不是全局变量
g 是 Flask 提供的请求上下文绑定对象，生命周期与单个请求严格对齐。它**不是**跨请求共享的容器，也不是进程级全局变量——误以为 g 能在不同请求间传递数据，是初学者最常踩的坑。
它的底层依赖 werkzeug.local.Local，在多线程（或使用 gevent/asyncio 时配合正确中间件）下能隔离各请求的数据。一旦请求结束，g 实例即被清空，下次请求会拿到一个全新的空 g。
- 不要在
before_first_request或模块顶层赋值g.xxx—— 此时无请求上下文，会直接报RuntimeError: Working outside of application context - 不要试图在后台线程中访问
g—— 线程无 Flask 请求上下文，g不可用 - 异步视图（
async def）中可安全使用g，但需确保用的是 Flask 2.0+ 且 ASGI 服务器（如 Uvicorn）已正确配置上下文传播
正确初始化和使用 g 的典型模式
最稳妥的做法是在 before_request 中设置所需属性，确保每次请求都有确定的初始状态。比如注入数据库连接、当前用户、请求 ID：
@app.before_request
def init_g():
g.request_id = str(uuid.uuid4())
g.db = get_db_connection() # 假设这是线程安全的连接工厂
g.user = get_current_user_from_token(request.headers.get("Authorization"))
- 所有对
g的读写必须发生在请求上下文中（即视图函数、after_request、teardown_request等钩子内） - 避免在
g上存大对象（如整个用户 profile 字典），优先存轻量引用或 ID，按需懒加载 - 若需清理资源（如关闭
g.db），务必在teardown_request中处理，否则可能引发连接泄漏
为什么不能用 g 替代 session 或 cache？
g 的数据只存在于当前请求生命周期内，不会自动序列化、加密、落盘或跨服务传递。它和 session（基于 cookie 或服务器端存储）、cache（如 Redis）、甚至 app.config 完全不在同一抽象层级。
- 需要“用户刷新页面后仍存在”的数据 → 用
session - 需要“多个请求共用一份计算结果”（如查一次 DB 复用多次）→ 用
cache或函数级缓存（functools.lru_cache配合请求 ID key） - 需要“整个应用启动后就存在的配置” → 放
app.config或独立配置模块 -
g只适合：“本次请求里，我多个函数都要用到这个临时值，又不想层层传参”
调试 g 数据丢失或错乱的常见线索
如果发现 g.xxx 在视图里是 None，或在并发压测中出现 A 请求看到 B 请求的 g.user，基本可锁定为上下文管理问题：
- 检查是否在非请求上下文中调用了
g.xxx（例如单元测试没用app.test_request_context()） - 确认 WSGI 服务器未开启多进程 + 单线程模式（如 Gunicorn 的
--preload+--threads 1），这种组合会导致Local失效 - 若用了 Celery，注意其任务运行在独立进程中 ——
g对 Celery 任务完全不可见，必须显式传参 - 打印
id(g)和threading.get_ident()可快速验证是否真正在不同线程/协程中拿到了不同的g
真正容易被忽略的点：g 的“安全”仅限于请求边界内。它不提供任何数据校验、过期控制或跨服务一致性保障 —— 这些都得靠你自己的设计补足。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
