g对象不是跨请求的全局变量，只在单个请求生命周期内有效；它是Flask为每次请求独立创建的上下文局部对象，基于werkzeug.local.Local实现线程/协程隔离，请求结束即清空，下次请求为全新实例。
g对象不是跨请求的全局变量，只在单个请求生命周期内有效
很多人误以为 g 是 Flask 的“全局变量”，能像模块级变量一样在不同请求间共享数据——这是危险误解。g 实际是请求上下文（RequestContext）绑定的临时容器，每个请求都有独立的 g 实例。一旦请求结束（响应返回、异常中断或超时），该 g 就被丢弃，下个请求拿到的是全新的空 g。
典型错误现象：g.user_id 在 before_request 中设了，但在视图函数里取不到，或者取到的是上一个请求残留的值——大概率是因为用了多线程/异步模式但没正确触发上下文，或误在非请求上下文中访问 g。
实操建议：
- 只在
before_request、视图函数、teardown_request等明确处于请求上下文中的位置使用g - 避免在后台线程、定时任务、信号回调中直接读写
g，它们没有请求上下文 - 调试时可用
hasattr(g, 'user_id')或getattr(g, 'user_id', None)安全访问，而非直接g.user_id
用 g 存储请求级中间数据比传参更干净，但别存大对象
g 最合理的用途，是把本该层层传递的请求级数据（如当前用户、数据库连接、请求 ID、权限上下文）集中托管，避免在 5 层嵌套函数调用中反复传 user 或 db 参数。
示例场景：你有一个 get_current_user() 函数，在 before_request 中调用并存入 g.user，后续所有业务函数直接从 g.user 取值即可。
但要注意：
- 不要往
g里塞大型对象（如 pandas DataFrame、未关闭的文件句柄），它们不会自动释放，可能引发内存缓慢增长 - 避免存可变对象后在多个地方修改——虽然同请求内是同一个引用，但逻辑耦合会变强，调试困难
- 如果需要清理资源（如 DB 连接），务必在
teardown_request中显式关闭，不能依赖g自动销毁
g 和 session、request 的关键区别必须分清
g、session、request 都是 Flask 常用的上下文对象，但职责完全不同：
-
request：只读，封装客户端 HTTP 请求数据（request.args、request.json等），不可写 -
session：加密签名的客户端 Cookie 存储，跨请求持久化（如登录态），有大小限制（通常 4KB），不安全存敏感数据 -
g：纯服务端内存存储，仅限当前请求生命周期，无序列化/传输开销，适合临时中间状态
常见混淆点：g.user = user 后希望下次请求还能访问——不行，那是 session 的事；想在模板里用 g.site_name，但忘了在 before_request 中设置——模板渲染时会报 AttributeError。
用 app_ctx 而非 req_ctx 时 g 行为不同，要主动管理
Flask 1.0+ 支持应用上下文（app.app_context()），比如在 shell 或 CLI 命令中模拟运行。此时 g 依然存在，但它绑定的是应用上下文，不是请求上下文——没有 request、session，也没有自动的 before_request 触发。
这意味着：
- 在
flask shell里直接用g是合法的，但它是独立于任何请求的“额外”实例 - 如果你在 CLI 命令中手动 push 了
app_context，又想复用类似请求中的初始化逻辑，得自己调用初始化函数（比如init_g_for_cli(g)） - 测试时若用
app.test_request_context()，g才真正模拟请求行为；只用app.app_context()则不会触发before_request
最易忽略的是：某些扩展（如 Flask-SQLAlchemy）内部会依赖请求上下文初始化，若在纯 app_context 下误用 g 存 DB 实例，可能引发隐晦的连接错误。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
