select_for_update() 是唯一能保证「读到的值在写回前始终有效」的 orm 原生方案，必须配合 transaction.atomic() 使用，否则锁无效；其锁粒度依赖查询是否走索引，且仅对查询结果集中的行生效。
因为普通查询读完就释放锁，后续 save() 时数据可能已被别人改掉——select_for_update() 是唯一能保证「读到的值在写回前始终有效」的 ORM 原生方案。
为什么不用 select_for_update 就会丢数据
典型场景：两个请求同时读取库存为 10，各自减 1 后都写回 9，最终变成 9 而不是预期的 8。这不是 Django 的 bug，而是所有「读-改-写」操作在无锁情况下必然发生的竞态。
常见错误现象包括：
-
IntegrityError: duplicate key value violates unique constraint（比如抢购生成重复订单号） - 余额扣成负数、计数器增长慢于实际请求数
- 日志里看到大量重复的旧值读取记录
select_for_update() 必须和 transaction.atomic() 一起用
单独调用 select_for_update() 不会加锁，也不会报错——它只是生成一条带 SELECT ... FOR UPDATE 的 SQL，但若不在事务中执行，MySQL 默认静默忽略，PostgreSQL 则直接报错。
实操要点：
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
- 必须包裹在
with transaction.atomic():或@transaction.atomic装饰器内 - 不能在
get_or_create()、update_or_create()链式调用里直接加select_for_update()，它们不保证事务上下文 - SQLite 完全不支持行锁，测试时看着正常，切到 PostgreSQL/MySQL 才暴露问题
锁不住行？大概率是查询没走索引
select_for_update() 的锁粒度完全依赖数据库执行计划。如果 WHERE 条件没命中索引，MySQL 可能升级为表锁，PostgreSQL 也可能锁住远超预期的行。
高频踩坑点：
- 用
filter(id__in=[])→ 实际生成WHERE id IN ()，结果集为空，不触发加锁 - 只调
filter().select_for_update()没接.get()或.first()→ QuerySet 延迟到真正求值时才发 SQL，此时事务可能已结束 - 用非索引字段过滤（如
name="iPhone"），尤其在 MySQL 上极易引发表级锁定
nowait 和 skip_locked 参数不是所有数据库都支持
MySQL 8.0 之前不支持 nowait=True 和 skip_locked=True，强行设置会抛 DatabaseError；PostgreSQL 全支持，但 of=['field_name'] 仅它可用，MySQL 直接忽略。
参数选择逻辑：
-
nowait=True：适合需要快速失败的场景（如秒杀下单），拿不到锁立刻抛异常，由业务决定重试或降级 -
skip_locked=True：适合队列消费类任务，跳过已被锁的行继续处理，避免 worker 卡死 -
nowait和skip_locked互斥，同时设会触发ValueError
最常被忽略的一点：锁的是「查询结果集里的行」，不是「模型实例」。你锁了 A 行，却调用 B 行的 save()，或者用 update() 绕过实例直接发 SQL，锁就白加了。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
