g是Flask为每次请求单独创建的临时命名空间，不跨请求、不跨线程、不持久化；仅在当前请求上下文中有效，需在before_request中初始化、teardown_request中清理。
Flask 中的 g 是什么，它真能跨请求存数据吗？
g 不是全局变量，也不是进程/线程级共享变量。它是 Flask 为每个请求单独创建的临时命名空间，生命周期仅限于一次请求处理过程。你写 g.user_id = 123，下个请求里 g 就是空的——这是最常见的误解起点。
常见错误现象：AttributeError: 'LocalProxy' object has no attribute 'xxx'，往往是因为在未初始化 g 的地方直接读取，比如在 before_request 外提前访问，或在异步任务、后台线程里误用。
-
g只在当前请求上下文中有效；脱离请求（如 Celery 任务、定时器、新线程）访问会报错或返回空值 - 它不跨请求、不跨线程、不持久化，和
session或数据库完全不是一回事 - 初始化必须显式做，Flask 不自动填充任何字段，
g初始就是个空容器
什么时候该用 g，而不是用 session 或参数传递？
核心判断标准：是否需要在**同一个请求内多个函数之间共享轻量状态**，且这些函数**没有直接调用链关系**（比如中间件、装饰器、工具函数、模板上下文处理器）。
典型使用场景：
立即学习“Python免费学习笔记（深入）”；
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
- 解析 JWT 后把当前用户信息存到
g.current_user，后续视图、表单验证、日志记录都可直接读取，不用层层传参 - 在
@app.before_request中打开数据库连接并赋给g.db，然后在任意视图或模型方法中复用这个连接（注意：需配合@app.teardown_request关闭） - 记录请求 ID（
g.request_id）用于全链路日志追踪，模板里也能直接 {{ g.request_id }}
不该用 g 的情况：
需要跨请求记住用户偏好 → 用 session；需要长期存储 → 用数据库或 Redis；需要并发安全的计数器 → 用 threading.local() 或专用服务。
g 的初始化和清理必须配对，否则会泄漏资源
Flask 不帮你管理 g 里的对象生命周期。如果你往 g 里塞了数据库连接、文件句柄或缓存实例，不显式清理，它们会在请求结束后滞留，可能引发连接池耗尽、文件描述符泄漏等问题。
- 初始化写在
@app.before_request里，例如：@app.before_request<br>def before_request():<br> g.db = get_db_connection()
- 清理必须写在
@app.teardown_request（即使出错也要执行）：@app.teardown_request<br>def teardown_request(exception):<br> if hasattr(g, 'db'):<br> g.db.close()
- 不要依赖
finally或函数返回逻辑来清理 —— 请求上下文销毁时，g本身会被丢弃，但里面引用的对象不会自动释放
为什么在单元测试里 g 总是空的？
因为测试客户端（app.test_client()）默认不激活请求上下文，g 不会自动构造。你得手动推入上下文，或者用更稳妥的方式模拟。
- 正确做法：用
app.app_context()+app.test_request_context()嵌套：with app.app_context():<br> with app.test_request_context():<br> g.user_id = 456<br> # 此时才能安全访问 g
- 更推荐在测试 setup 阶段统一 push 上下文，并在 teardown pop 掉
- 如果只是想测某个函数是否正确读取
g，别直接调函数，而是走完整请求流程（client.get('/path')），让 Flask 自动管理上下文
最易被忽略的一点：g 的行为高度依赖 Flask 的上下文栈机制，而这个机制在非 Web 环境（如 CLI 命令、shell 脚本、异步任务）中默认不存在 —— 这时候强行用 g，不是报错就是静默失效。
