Flask的g对象是请求级上下文绑定的临时容器，仅在单个请求生命周期内有效，不可跨请求共享，非请求上下文中需用app_context替代request_context，并避免存储大对象或连接实例以防内存泄漏。
Flask的g对象不是全局变量，而是请求级上下文绑定的临时容器
很多人误以为g能跨请求共享数据，其实它只在单个请求生命周期内有效。一旦请求结束，g就被清空；下个请求进来时是全新实例。如果你在before_request里赋值g.user_id = 123，那后续同请求内的视图、模板、工具函数都能读到，但绝不会泄漏到其他请求里。
常见错误现象：AttributeError: 'LocalProxy' object has no attribute 'db_conn'——通常是因为在非请求上下文中（比如后台线程、shell命令、定时任务）直接访问g，此时没有激活的请求上下文。
- 仅在已进入请求上下文后使用：确保代码运行在
request_context或app_context内 - 不要在模块顶层或
__init__.py中直接读写g - 若需跨请求持久化，改用
cache、Redis 或数据库，而非g
跨模块读写g必须确保上下文已推送
Flask默认只在请求处理链路中自动推送上下文（如@app.route函数内）。但当你把逻辑拆到独立模块（比如utils/auth.py或models/order.py），这些文件被导入时并不自动拥有上下文。
典型场景：你在api/v1/orders.py里调用order_service.create()，而后者又依赖g.current_user——如果没显式处理，就会报错。
- 推荐做法：在服务函数入口加
@app.before_request统一初始化g字段，或在调用前检查has_request_context() - 安全读取方式：
getattr(g, 'current_user', None)，避免直接g.current_user触发RuntimeError - 测试时手动推送上下文：
with app.test_request_context(): ...
用app_context替代request_context管理非HTTP场景的g
命令行脚本、Celery任务、Shell调试（flask shell）等没有HTTP请求，但你仍可能想用g暂存一些运行时状态（比如当前环境配置、调试开关）。这时要用app.app_context()，而非request_context()。
注意：app_context不包含request相关属性（如request.args），但它能让g正常工作，且生命周期与应用上下文一致。
- 正确示例：
with app.app_context(): g.debug_mode = True run_migration() - 错误示例：
with app.test_request_context():—— 在无请求的场景下会抛RuntimeError -
g在app_context中依然不能跨进程/线程共享，多进程部署时每个worker有独立g
g不适合存储大对象或连接实例，容易引发内存泄漏
有人习惯把数据库连接、Redis客户端、大型缓存字典塞进g，认为“一个请求用一个就够了”。但Flask不会自动关闭或清理它们，尤其当请求异常中断（如超时、500错误）时，g里的资源可能一直挂着。
更稳妥的做法是结合teardown_appcontext或teardown_request做显式释放。
- 优先用连接池（如SQLAlchemy的
scoped_session），而不是手管g.db_conn - 若必须存连接，注册清理钩子：
@app.teardown_appcontext def close_db(error): if hasattr(g, 'db_conn'): g.db_conn.close() - 避免存
bytes、dict等大结构体——它们会随请求生命周期滞留，增加GC压力
g里塞东西，而是判断什么时候不该用它。跨模块通信如果开始需要反复检查has_request_context()、加getattr(..., None)兜底、还要写teardown清理，往往说明该抽成独立服务或传参了。Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
