为什么在Python Flask中使用Global变量会导致并发数据错乱？-Python教程-PHP中文网

flask中global变量并发出错是因为其在多线程/多进程下被所有请求共享，缺乏隔离与同步机制，导致数据覆盖、丢失或错乱；正确做法是用flask.g（单请求生命周期）、threading.local（线程局部）或redis/数据库（跨请求持久化）。

为什么在python flask中使用global变量会导致并发数据错乱？

Flask里用`global`变量为什么一并发就出错？

因为global变量在多线程（或异步 worker）下是共享的，而 Flask 默认用多线程模式跑多个请求——同一变量被不同请求同时读写，没加锁就会覆盖、丢失、返回错值。

典型现象：用户 A 提交 user_id=100，用户 B 同时提交 user_id=200，但 A 的接口返回了 200；或者某次请求看到的是上一次请求残留的中间状态。

Flask 开发服务器默认启用 threaded=True，每个请求走独立线程，但共享进程级全局命名空间
global 变量不是线程局部的，也不随请求生命周期自动隔离
即使你只在单个 route 里改 global x，只要两个请求进得够快，就可能交叉执行赋值和读取

什么场景下误以为`global`能“暂存请求数据”？

常见于想绕过参数传递，比如在装饰器里临时记下当前用户 ID，然后在视图函数里直接读——这本质上把线程不安全的全局变量当成了“本次请求上下文”。

错误示例：

Python 3.14.2

Python 3.14.2是Python编程语言在2025年12月5日发布的稳定版本，属于3.14系列的第二个维护更新。该版本包含了18项修复，重点解决了多进程、数据类及正则表达式等模块的回归问题，并修复了CVE-2025-12084等安全漏洞。此版本标志着自由线程模式（移除GIL）正式获得官方支持，是Python发展的重要里程碑。

下载

current_user_id = None
<p>@app.before_request
def set_user():
global current_user_id
current_user_id = request.headers.get("X-User-ID")</p><p>@app.route("/profile")
def profile():
return {"user_id": current_user_id}  # ❌ 并发时可能返回别人的数据
</p>

这个 current_user_id 是整个进程共用的，不是 per-request
@app.before_request 在不同线程里反复覆盖它，没有任何同步保障
哪怕你用 threading.local() 手动模拟，也容易漏掉清理，不如用 Flask 原生机制

替代方案：用`flask.g`还是`flask.session`？

flask.g 是线程/协程局部的，生命周期绑定单次请求，适合临时存储请求内共享数据；flask.session 是客户端加密存储，适合跨请求保持（如登录态），但别存敏感中间状态。

用 g：适合中间件注入、DB 连接、解析后的 token payload 等——只在当前请求内有效
用 session：适合用户偏好、表单草稿等需“下次还记住”的东西，但注意 session 有大小限制和签名开销
千万别用 g 存需要持久化或跨请求访问的东西——请求一结束它就销毁

正确写法：

from flask import g, request
<p>@app.before_request
def load_user():
g.user_id = request.headers.get("X-User-ID")  # ✅ 每个请求独立一份</p><p>@app.route("/profile")
def profile():
return {"user_id": g.user_id}  # ✅ 安全
</p>

如果真要跨请求共享状态，该用什么？

全局变量不是不能用，而是不能直接裸用。需要明确区分“共享配置”和“共享状态”：

只读配置（如 APP_ENV, MAX_RETRY）可以用 global 或模块级常量，没问题
可变状态（如计数器、缓存、用户会话映射）必须用线程安全结构：threading.Lock + dict，或更稳妥地交给 redis / memcached
Flask 扩展如 Flask-Caching 或 Flask-Login 已封装好并发安全逻辑，优先复用