select_for_update 只在 transaction.atomic() 事务块内生效，否则数据库忽略锁提示；需确保查询条件命中索引、避免空 in 查询、用锁对象调 save() 而非 update()，并合理选用 nowait/skip_locked/of 参数。
select_for_update 什么时候才真正加锁
它只在数据库事务里生效，且必须配合 transaction.atomic() 使用。单独调用 select_for_update() 不会加锁，也不会报错——只是生成一条带 SELECT ... FOR UPDATE 的 SQL，但若不在事务中执行，数据库直接忽略锁提示（PostgreSQL 会报错，MySQL 默认静默降级）。
常见错误现象：select_for_update() 返回结果正常，但并发写入仍出错；或日志里看到 SQL 执行了，却没锁住行。
- 必须包在
with transaction.atomic():块内 - 不能在
get_or_create()或update_or_create()里直接链式调用select_for_update()，它们内部不保证事务上下文 - SQLite 不支持行锁，测试时用它会“假装成功”，切到 PostgreSQL/MySQL 才暴露问题
select_for_update 的参数怎么选：nowait、skip_locked、of
默认行为是阻塞等待锁释放，但生产环境通常要避免无限等待。三个关键参数决定锁策略：
-
nowait=True：拿不到锁立刻抛DatabaseError（PostgreSQL）或OperationalError（MySQL），需主动捕获处理 -
skip_locked=True：跳过已被锁的行，常用于队列消费场景，避免 worker 卡住；注意 Django 3.2+ 才支持，旧版本无效 -
of=['field_name']：指定只锁某张表的某些字段对应行（多表 join 时精准控制范围），但仅 PostgreSQL 支持，MySQL 忽略该参数
性能影响：加锁本身开销小，但锁等待会拖慢响应；nowait 可提升吞吐，代价是业务逻辑要处理失败分支。
立即学习“Python免费学习笔记（深入）”；
为什么 select_for_update 锁不住预期的行
根本原因通常是查询条件没走索引，导致数据库升级为表锁或锁范围过大。Django 的 select_for_update() 依赖底层 SQL 的 WHERE 条件是否能命中索引。
- WHERE 字段没建索引 → MySQL 可能锁全表，PostgreSQL 锁整个扫描范围
- 用了
__in查多个主键，但传入列表为空 → 查询变成WHERE id IN ()，部分数据库返回空结果集，不触发加锁 - 用
filter()但没加get()或first()→ 返回的是 QuerySet，锁语句延迟到实际求值时才发，若中间有其他 DB 操作，事务可能已结束
验证方法：打开 LOGGING 配置，看实际执行的 SQL 是否含 FOR UPDATE，再用 EXPLAIN 检查执行计划。
并发更新时仍出现数据覆盖怎么办
select_for_update 解决的是“读-改-写”中间被篡改的问题，但它不阻止你代码里自己写错逻辑。典型坑是：锁了 A 行，却更新了 B 行；或锁了对象但用 .update() 走 bulk SQL，绕过实例状态。
- 必须用锁住的对象调用
.save()，而不是新建实例再 save - 避免混合使用
select_for_update()和update()：后者不经过 ORM 实例，无法保证基于最新锁后状态 - 如果业务需要原子计数（如库存扣减），优先用
F()表达式 +select_for_update()，例如obj.count = F('count') - 1
最容易被忽略的一点：锁只对当前事务可见，不同请求的事务彼此隔离，但如果你在锁块里调了外部 HTTP 接口或发消息，这段时间锁一直占着，容易引发长事务和锁竞争。
