version_id未起作用的根本原因是未正确启用或未纳入事务边界：需在模型中显式声明version_id=True的整型列、禁用default/server_default、确保UPDATE走ORM方法而非原生sql，且mysql不支持RETURNING导致StaleDataError延迟抛出。
并发更新时数据被悄悄覆盖，version_id_col 为什么没起作用
根本原因通常是 version_id_col 没被正确启用或没进事务边界。SQLAlchemy 的乐观锁不是自动全局生效的——它只在你显式声明了 version_id_col=True 且该列参与 UPDATE WHERE 条件时才触发校验。
- 必须在模型定义里用
column(Integer, Nullable=False)显式声明字段，并传入version_id=True（注意不是version_id_col参数名） - 该字段不能是
default或server_default，必须由 SQLAlchemy 在每次 update 时自增，否则 UPDATE 的 WHERE 子句不会包含它 - 所有并发修改必须走同一个
session.merge()或session.query().Filter().update()流程，直接session.execute("UPDATE ...")会绕过乐观锁 - postgresql 和 sqlite 支持
RETURNING，但 MySQL 不支持，所以用session.commit()后才抛StaleDataError，而不是在执行 UPDATE 时就失败
flask 视图里怎么捕获并重试 StaleDataError
不能靠 try-except 包整个 request handler，因为 session 生命周期和事务边界要对齐。最稳妥的做法是在业务逻辑层封装重试，而不是在路由函数里硬塞循环。
- 把核心更新逻辑抽成独立函数，接受
session和重试次数参数，内部用try/except sqlalchemy.orm.exc.StaleDataError - 每次捕获后调用
session.refresh(obj)再重新计算变更，而不是直接session.rollback()—— 后者会丢掉其他已做的改动 - 别在 Flask 的
@app.route函数里做多次session.commit()，容易引发“Session is closed”错误；重试应在同一事务内完成 - 示例：
def update_balance(session, user_id, delta): for _ in range(3): try: user = session.get(User, user_id) user.balance += delta session.commit() return user.balance except StaleDataError: session.rollback() continue raise RuntimeError("Too many conflicts")
什么时候不该用 version_id，而该换悲观锁或队列
乐观锁适合读多写少、冲突概率低的场景。如果两个接口高频修改同一张表的同一行（比如库存扣减），StaleDataError 会频繁抛出，重试成本反而更高。
- 高冲突场景下，
select ... FOR UPDATE更可靠，但要注意数据库隔离级别和死锁风险（尤其跨多行时） - Flask 中用
session.execute(text("SELECT ... FOR UPDATE"), {"id": x})手动加锁，记得配autocommit=False - 更彻底的解法是把写操作发到 redis 队列或 Celery，用单 worker 串行处理，避免数据库层争抢
-
version_id对批量更新（如session.query(User).filter(...).update({...})）无效——它只保护单对象实例，不保护 query.update
SQLite 和 MySQL 下 version_id 行为差异坑点
SQLite 默认不支持行级锁，FOR UPDATE 是空操作；MySQL 的 InnoDB 虽支持，但如果你用的是 MyISAM 引擎，乐观锁照样失效——它压根不支持事务。
- SQLite 下
StaleDataError只能在commit()时检测到，因为没有真正的并发控制机制 - MySQL 必须确认表引擎是 InnoDB，用
SHOW CREATE table users查；MyISAM 下version_id字段存在也没用 - PostgreSQL 最友好，UPDATE 自带
WHERE version = old_version并返回影响行数，能立刻知道是否冲突 - 测试时别只用 SQLite 做并发验证，换 docker 起个真实 MySQL 实例跑压测
事情说清了就结束。真正难的不是加 version_id=True，而是判断哪条路径会绕过 ORM、哪个数据库特性会让它静默失效。