LocalStack 是 Werkzeug 提供的线程/协程隔离栈，每个线程持独立栈副本，栈顶为当前上下文；但它不自动传播到子线程，故手动启线程时需显式调用 app.app_context() 等重建上下文。
Flask 默认不是线程安全的“开箱即用”框架——它依赖上下文隔离，而不是自动加锁。真正起作用的是 werkzeug.local.LocalStack 和底层的 threading.local，但这个机制只在请求生命周期内由 Flask 自动维护；一旦你主动创建子线程、启动后台任务或脱离请求上下文，就立刻失效。
LocalStack 是什么，为什么它不自动保护你的子线程
LocalStack 是 Werkzeug 提供的上下文栈管理器，request、g、current_app 都靠它推入/弹出。它的本质是：
- 每个线程（或协程）持有一个独立的栈副本
- 栈顶元素就是当前上下文（比如当前请求的
RequestContext） - 但这个栈不会跨线程传播，也不会在你手动
threading.Thread启动时自动初始化
常见错误现象：RuntimeError: Working outside of application context 或 AttributeError: 'NoneType' object has no attribute 'query'
典型场景：
- 在视图函数里用
threading.Thread(target=background_job).start() - 在定时任务（如 APScheduler）中直接调用
db.session - 把
current_app当全局变量缓存在模块顶层
正确做法不是“绕过上下文”，而是显式重建上下文：
-
with app.app_context():—— 用于无请求的后台逻辑（如定时任务、命令行脚本） -
with app.test_request_context():—— 用于模拟请求环境（测试或内部构造） - 不要复用
app实例本身，而要用它来推入新上下文
db.session 看似线程安全，实则依赖上下文绑定
SQLAlchemy 的 scoped_session 默认使用 threading.local，但它只在 Flask 请求上下文激活时才被正确绑定到当前线程。否则：
立即学习“Python免费学习笔记（深入）”；
-
db.session可能返回None（未初始化） - 或返回其他线程残留的会话（导致数据污染）
- 或触发
sqlite3.ProgrammingError: SQLite objects created in a thread can only be used in that same thread
关键点：
-
db.session不是“线程安全对象”，而是“按线程隔离的对象”，前提是上下文已就位 - 即使你用了连接池（
create_engine(..., pool_pre_ping=True)），也不能跳过app_context - 不要手动保存
db.session到类属性或全局变量，它必须每次从上下文中动态获取
示例错误写法：
class Worker:
session = db.session # ❌ 错！session 会随上下文变化，这里固定引用无效
正确写法：
def background_task():
with app.app_context():
users = db.session.query(User).all() # ✅ 每次都用当前上下文里的 session
sqlite3.Connection 为什么不能设 check_same_thread=False
很多人看到报错第一反应是加 check_same_thread=False，但这只是掩盖问题：
- 它让 SQLite 连接允许跨线程使用，但不保证事务一致性或并发读写安全
- 多个线程同时执行
INSERT或UPDATE仍可能因锁竞争失败，或读到脏数据 - 它绕过了 SQLite 的线程隔离设计初衷，反而增加调试难度
你应该做的是：
- 放弃全局连接（
conn = sqlite3.connect(...)在模块顶层） - 改用
SQLAlchemy+ 连接池（create_engine('sqlite:///app.db', pool_pre_ping=True)） - 或者在每个线程内按需创建+关闭连接（适合轻量脚本，不适合高频 Web 请求）
更现实的取舍：SQLite 本就不适合高并发写入场景。如果真有并发写需求，换 PostgreSQL 或加队列（如 Celery）才是正解。
LocalStack 机制本身很轻量，但它不是万能胶——它只负责“隔离”，不负责“同步”。你仍需自己判断：哪些操作需要加锁（比如共享内存计数器），哪些只需上下文（比如 g.user），哪些根本该交给异步任务系统处理。最容易被忽略的，是那些看似“只读”的操作：只要涉及 db.session 或 current_app，就一定得先确认上下文是否存在。
