g仅在单个请求生命周期内有效，不能跨请求共享数据，也不能替代session或数据库；它是Flask为每次请求独立创建的上下文本地对象，基于线程/协程局部存储，请求结束即清空，下次请求为全新实例。
g 只在单个请求生命周期内有效，不能跨请求共享数据，也不能替代 session 或数据库。
为什么 g 不能存用户登录态或跨请求数据
g 是 Flask 提供的请求上下文本地对象，底层基于 Local（类似线程/协程局部存储），每个请求都有独立的 g 实例。一旦请求结束，g 就被清空，下次请求是全新的对象。
- 常见错误：在
@app.before_request中查数据库把用户信息塞进g.user，然后以为后续所有请求都能读到——其实只对当前请求生效 - 更隐蔽的坑：用异步视图（如
async def）+g，若未正确 await 或上下文未激活，g可能为 None 或报RuntimeError: Working outside of application context - 多线程/多进程部署时（如 gunicorn 多 worker），
g绝对不共享，也无需担心并发冲突
什么场景下该用 g？典型例子
它最适合做「当前请求内部」的轻量级缓存或中间传递，避免重复计算或层层传参。
- 数据库连接：在
before_request中创建g.db = get_db_connection()，视图里直接用，teardown_request关闭 - 解析后的请求参数：比如统一校验 JWT 后把 payload 存为
g.jwt_payload，多个视图函数都可读取，不用重复 decode - 日志上下文：存
g.request_id或g.user_ip，方便日志打点关联 - 注意：
g不是全局变量，不能在非请求上下文中访问（如后台定时任务、shell 命令中），否则会触发上下文错误
如何安全地初始化和清理 g 数据
必须成对使用 before_request 和 teardown_request（或 after_request），尤其涉及资源（如连接、文件句柄）时。
立即学习“Python免费学习笔记（深入）”；
@app.before_request
def before_request():
g.db = get_db_connection()
g.start_time = time.time()
@app.teardown_request
def teardown_request(exception):
if hasattr(g, 'db'):
g.db.close()
-
teardown_request保证无论是否出错都会执行，适合清理；after_request只在响应成功生成后调用，异常时跳过 - 不要依赖
g的属性是否存在来判断初始化状态——应显式检查hasattr(g, 'xxx')或用getattr(g, 'xxx', default) - 避免在
g中存大型对象（如整个 DataFrame、大字典），它不释放内存直到请求结束，可能拖慢响应或撑爆内存
g 和 session、request 的关键区别
三者完全不是同一类东西，混用会导致逻辑混乱：
-
request：只读，封装原始 HTTP 请求（request.args,request.json等），不可写 -
session：加密签名的客户端 cookie，用于跨请求保持少量用户数据（如session['user_id']），有大小限制（通常 4KB） -
g：纯服务端内存，仅当前请求可见，无序列化/传输开销，适合临时中间值 - 错误做法：把敏感 token 放
g.token后又试图在模板里用{{ g.token }}——Jinja 模板默认无法访问g，需手动传入或用context_processor
最常被忽略的一点：g 的生命周期严格绑定于 Flask 的请求上下文，而上下文在测试、CLI 命令、信号回调等场景中默认不存在——要用 app.app_context() 或 app.test_request_context() 显式推入，否则一碰 g 就报错。
