Flask中不能用全局变量存查询结果，因其被所有请求共享导致线程不安全和上下文混淆；g对象为单请求生命周期设计，可安全缓存如用户实例等临时数据。
为什么不能直接用全局变量存查询结果
Flask 的请求是并发处理的，如果把数据库查询结果直接赋值给模块级变量（比如
），多个请求会共享同一份数据，导致脏读、覆盖或线程安全问题。更关键的是，不同请求可能需要不同用户的上下文，全局变量根本分不清“这是谁的数据”。
对象正是为解决这个而生——它在每次请求开始时自动创建、请求结束时自动销毁，生命周期与单次请求严格对齐。
怎么用
缓存一次查询结果供同请求内多次使用
典型场景：一个视图函数里，先查用户基本信息，中间调用某个工具函数又需要用户权限，最后渲染模板还要用用户头像。如果三次都走 DB 查询，纯属浪费。正确做法是在首次查询后把结果挂到
上：
立即学习
“
Python免费学习笔记（深入）
”；
Python 3.14.3
微软官方的 Python 扩展，是 VS Code 安装量最高的扩展（209M+）。集成 IntelliSense（通过 Pylance）、调试（通过 Python Debugger）、代码检查、格式化、重构和单元测试等功能。支持 Jupyter Notebook、虚拟环境管理和多 Python 版本切换。
下载
注意两点：
是必须的判断，否则未触发
时访问会抛
；
不是万能钩子，它不捕获 WebSocket 或 CLI 命令等非 HTTP 请求上下文。
和
容易混淆的边界在哪
是请求级临时容器，只活在当前 HTTP 请求生命周期内；
是用户级持久化存储（默认基于签名 cookie），跨请求存在。常见误用是把需要长期记住的数据（如登录态 token）往
里塞——请求一结束就丢了。反过来说，别把敏感信息（如数据库密码、API key）放
，而
存临时对象反而更安全，因为它根本不出服务器内存。
：适合存本次请求解析出的用户模型实例
：适合存用于下一次请求识别身份的 ID
：适合存本次请求专用的数据库连接（避免多线程混用）
：配置类常量，该用应用上下文就用
，别塞
缓存失效和清理的实操要点
不提供自动失效机制，它只保证“请求结束即清空”，所以你不需要手动删键。但要注意：如果你在中间件、装饰器或异常处理路径中提前修改了
的值（比如重置
），后续逻辑可能拿到错误状态。更隐蔽的问题是，在单元测试中模拟请求时，
不会自动初始化，必须显式
或
才能用。
另外，不要试图把大对象（如千条记录的列表、二进制图片）塞进
——它只是字典，没做任何序列化或压缩，内存占用直线上升，还可能拖慢 GC。高频小对象（用户、配置片段、请求参数解析结果）才适合。
user_cache = Nonegggfrom flask import Flask, g, request
from your_db_module import get_user_by_id
app = Flask(name)
@app.before_request
def load_user():
user_id = request.args.get('uid')
if user_id and not hasattr(g, 'current_user'):
g.current_user = get_user_by_id(user_id) # 只查一次，挂到 g
@app.route('/dashboard')
def dashboard():
同一请求中任意位置都能取，无需重复查
name = g.current_user.name if hasattr(g, 'current_user') else 'Guest'
role = get_user_role(g.current_user) # 工具函数也用 g.current_user
return f"Hello {name}, role: {role}"hasattr(g, 'current_user')@before_requestAttributeError@before_requestgsessiongsessiongsessiongg.usersession['user_id']g.db_conncurrent_app.config['SECRET_KEY']current_appgggg.current_usergwith app.app_context():with app.test_request_context():g