Flask中不能用全局变量存查询结果,因其被所有请求共享导致线程不安全和上下文混淆;g对象为单请求生命周期设计,可安全缓存如用户实例等临时数据。

为什么不能直接用全局变量存查询结果
Flask 的请求是并发处理的,如果把数据库查询结果直接赋值给模块级变量(比如 user_cache = None),多个请求会共享同一份数据,导致脏读、覆盖或线程安全问题。更关键的是,不同请求可能需要不同用户的上下文,全局变量根本分不清“这是谁的数据”。g 对象正是为解决这个而生——它在每次请求开始时自动创建、请求结束时自动销毁,生命周期与单次请求严格对齐。
怎么用 g 缓存一次查询结果供同请求内多次使用
典型场景:一个视图函数里,先查用户基本信息,中间调用某个工具函数又需要用户权限,最后渲染模板还要用用户头像。如果三次都走 DB 查询,纯属浪费。正确做法是在首次查询后把结果挂到 g 上:
from flask import Flask, g, request
from your_db_module import get_user_by_id
<p>app = Flask(<strong>name</strong>)</p><p>@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</p><p>@app.route('/dashboard')
def dashboard():</p><h1>同一请求中任意位置都能取,无需重复查</h1><pre class="brush:php;toolbar:false;">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_request 时访问会抛 AttributeError;@before_request 不是万能钩子,它不捕获 WebSocket 或 CLI 命令等非 HTTP 请求上下文。
图片提示词生成器?不止如此。 马甲系统 —— 把脑海中的画面,翻译成AI能理解的专业表达。 用得越多,它越懂你:首次需要多问几句确认方向,用久了几乎一说就懂。 用得越多,它越快:缓存机制让后续对话越来越省。 RAG进化:成功案例持续入库,越跑越聪明。 输入「新手指南」查看完整功能介绍
g 和 session 容易混淆的边界在哪
g 是请求级临时容器,只活在当前 HTTP 请求生命周期内;session 是用户级持久化存储(默认基于签名 cookie),跨请求存在。常见误用是把需要长期记住的数据(如登录态 token)往 g 里塞——请求一结束就丢了。反过来说,别把敏感信息(如数据库密码、API key)放 session,而 g 存临时对象反而更安全,因为它根本不出服务器内存。
-
g.user:适合存本次请求解析出的用户模型实例 -
session['user_id']:适合存用于下一次请求识别身份的 ID -
g.db_conn:适合存本次请求专用的数据库连接(避免多线程混用) -
current_app.config['SECRET_KEY']:配置类常量,该用应用上下文就用current_app,别塞g
缓存失效和清理的实操要点
g 不提供自动失效机制,它只保证“请求结束即清空”,所以你不需要手动删键。但要注意:如果你在中间件、装饰器或异常处理路径中提前修改了 g 的值(比如重置 g.current_user),后续逻辑可能拿到错误状态。更隐蔽的问题是,在单元测试中模拟请求时,g 不会自动初始化,必须显式 with app.app_context(): 或 with app.test_request_context(): 才能用。
另外,不要试图把大对象(如千条记录的列表、二进制图片)塞进 g——它只是字典,没做任何序列化或压缩,内存占用直线上升,还可能拖慢 GC。高频小对象(用户、配置片段、请求参数解析结果)才适合。
Python免费学习笔记(深入):立即使用
在学习笔记中,你将探索 Python 的核心概念和高级技巧!










