不能靠Python层“先查再比再改”防并发冲突，必须将版本校验下推至SQL的WHERE子句实现原子更新，并依据update()返回值（0表示失败）决定重试或报错。
直接结论：不能靠 Python 层“先查再比再改”来防并发冲突，必须把版本校验下推到 SQL 的 WHERE 子句里，用原子更新 + 返回值判断是否生效。
Django ORM 中 version 字段更新失败却没报错？
常见错误现象是：两个请求同时读到 version=5，各自算出新数据后都调用 .save()，结果后写入者无声覆盖前者——save() 成功返回，但业务逻辑已损坏。
根本原因是 save() 默认执行的是 UPDATE ... SET ... WHERE id = X，不检查 version；它不会自动加 AND version = 5 条件。
- 正确做法是显式在
filter()中带上版本条件：User.objects.filter(id=123, version=5).update(name='new', version=6) -
.update()返回值是整数：成功更新 1 行返回1，版本已变则返回0，此时必须重试或抛异常 - 别用
F('version') + 1替代显式版本号——它只防“自增覆盖”，不防“业务逻辑覆盖”（比如库存扣减时还要校验余额）
SQLAlchemy 怎么让 update 带 version 校验？
SQLAlchemy 没有内置乐观锁装饰器，但可通过 update().where() 手动拼装原子条件更新。关键不是“有没有锁”，而是“条件是否落在数据库语句里”。
立即学习“Python免费学习笔记（深入）”；
示例场景：扣减商品库存，要求 stock >= 10 且版本未变：
stmt = (
update(Product)
.where(Product.id == product_id, Product.version == expected_version, Product.stock >= 10)
.values(stock=Product.stock - 10, version=expected_version + 1)
)
result = conn.execute(stmt)
if result.rowcount == 0:
raise ConcurrentUpdateError("version changed or stock insufficient")
- 必须把
version和业务条件（如stock >= 10）一起写进where()，否则校验无效 - 不要依赖
session.merge()或session.add()+flush()，它们无法保证 WHERE 条件原子性 - 如果用
session.execute(stmt)，注意事务上下文要手动管理，避免隐式提交
TypeORM @VersionColumn 看似自动，但 update 仍可能失败
@VersionColumn() 确实会在 UPDATE 语句中自动加入 WHERE version = ?，但它只在调用 save() 时生效——而 save() 是“先 SELECT 再 UPDATE”，中间存在竞态窗口。
真正安全的用法是绕过 save()，直接走查询构建器：
const result = await connection
.createQueryBuilder()
.update(Post)
.set({ title: "new", version: () => "version + 1" })
.where("id = :id AND version = :version", { id, version: expectedVersion })
.execute();
if (result.affected === 0) {
throw new Error("Optimistic lock failed");
}
-
@VersionColumn对insert()和remove()也生效，但日常并发冲突集中在update - 别在事务外用
save()依赖乐观锁——事务内它仍会先查一次，只是锁粒度更小 - PostgreSQL 和 MySQL InnoDB 都支持该模式，SQLite 不支持行级锁，乐观锁是唯一可行方案
最容易被忽略的一点：所有乐观锁方案都假设你**能接受重试**。如果业务不允许重试（比如支付回调），那就得切回悲观锁——但必须确认数据库和事务配置真正在起作用，而不是静默失效。
