根本原因是数据库连接、ORM会话、应用上下文未按线程边界隔离：SQLite连接不可跨线程复用，db.session依赖请求上下文且非线程安全，current_app在子线程中因缺少app_context而抛RuntimeError。
Flask 多线程下数据错乱，根本原因不是“线程太多”，而是数据库连接、ORM 会话、应用上下文三者没按线程边界隔离——SQLite 连接不能跨线程用，db.session 不是线程安全的，current_app 在子线程里直接访问就报 RuntimeError。
SQLite 连接对象为什么不能跨线程使用
SQLite 默认禁止跨线程复用同一个 sqlite3.Connection 实例。这不是 bug，是设计选择：它靠“每个线程自己建连接”来规避锁竞争和状态混乱。
- 错误现象：
sqlite3.ProgrammingError: SQLite objects created in a thread can only be used in that same thread - 典型踩坑：在模块顶层写
conn = sqlite3.connect('app.db')，然后所有视图函数都去用这个conn - 正确做法：每个请求（即每个线程）内创建自己的连接，或用连接池（如
SQLAlchemy的create_engine(..., pool_pre_ping=True)） - 注意：即使你用的是
SQLAlchemy，如果手动调用了engine.connect()并全局保存了Connection对象，一样会触发该错误
SQLAlchemy 的 db.session 为什么不是线程安全的
db.session 是一个 scoped_session，它背后依赖 threading.local 实现“每线程一个会话”。但这个机制只在 Flask 请求上下文激活时才自动绑定；一旦脱离上下文（比如进子线程、异步任务、定时任务），db.session 就会返回错误的会话或报空引用。
- 错误现象：
AttributeError: 'NoneType' object has no attribute 'query'或读到其他请求的数据 - 常见场景：用
threading.Thread启动后台任务，在线程里直接调用db.session.query(...) - 解决方式：在线程内显式推入应用上下文 ——
with app.app_context(): ... - 额外提醒：不要在模块级或类属性里缓存
db.session，它必须随请求/线程生命周期动态获取
current_app 和 g 在子线程中为何失效
current_app 和 g 都是基于 werkzeug.local.LocalProxy 的代理对象，它们内部靠 threading.local 存储实际值。子线程没有被 Flask 自动注入上下文，所以代理找不到绑定目标。
立即学习“Python免费学习笔记（深入）”；
- 错误现象：
RuntimeError: Working outside of application context - 不要写：
from flask import current_app; current_app.config['SECRET_KEY']在线程函数里 - 要写：
with app.app_context(): print(app.config['SECRET_KEY']) - 更稳妥的做法：把需要的配置项提前取出传入线程，而不是在线程里反向查
current_app
什么时候该用锁，什么时候该避免锁
多数 Flask 场景下，你不该自己加 threading.Lock 去保护数据库操作——那只会掩盖设计缺陷，还可能引发死锁。真正的并发控制应该交给数据库层（如 SELECT ... FOR UPDATE）或业务层（如唯一约束、乐观锁版本号）。
- 该用锁的极少数情况：操作共享内存变量（如
g.counter）、写本地缓存文件、调用非线程安全的第三方 SDK - 不该用锁的情况：对同一张表做
UPDATE、INSERT—— 这些应由数据库事务和行锁保证一致性 - 性能影响：Python 的 GIL 只保解释器级安全，不保逻辑一致性；盲目加锁反而降低吞吐，且容易漏掉边界（比如忘记在异常路径释放锁）
最常被忽略的一点：Flask 的 app.run() 开启多线程只是开发便利，生产必须换 gunicorn 或 waitress；而这些 WSGI 服务器默认是多进程模式，这时线程局部变量（threading.local）完全失效——你要切换成进程安全的方案，比如 Redis 缓存、数据库状态标记、或用 multiprocessing.Manager。
