select_for_update()是Django 5.0并发库存扣减的首选，因其在数据库层面加行级写锁，强制并发请求排队，确保“读—改—写”原子性；必须置于transaction.atomic()中，且需先查出实例再save()，不可用filter().update()替代。
为什么 select_for_update() 是 Django 5.0 并发库存扣减的首选
直接结论：不用 select_for_update()，仅靠普通 ORM 查询 + save()，100% 会超卖。Django 5.0 默认数据库隔离级别（如 PostgreSQL 的 READ COMMITTED、MySQL 的 REPEATABLE READ）无法阻止两个事务同时读到旧库存值并各自减 1。
select_for_update() 在数据库层面加行级写锁，强制后续并发请求排队等待，是唯一能保证“读—改—写”原子性的标准方案。
- 必须在事务内使用：
with transaction.atomic():包裹，否则锁立即释放 - 必须查到要更新的行（不能用
filter().update()替代）：只有被select_for_update()查出的实例，在后续save()时才会触发带锁更新 - PostgreSQL 支持
skip_locked=True避免锁等待死锁；MySQL 不支持该参数，需手动加nowait=True并捕获DatabaseError
如何正确写一个防超卖的扣减函数
关键不是“能不能减”，而是“减完是否仍 ≥ 0”。不能先 save() 再校验，必须把校验和更新放在同一数据库语句中，或在锁保护下顺序执行。
from django.db import transaction
from django.db.utils import DatabaseError
<p>def deduct_stock(product_id: int, quantity: int) -> bool:
try:
with transaction.atomic():</p><h1>加锁查库存（注意：必须用 get() 或 filter().select_for_update().first()）</h1><pre class="brush:php;toolbar:false;"> product = Product.objects.select_for_update().get(id=product_id)
if product.stock <p></p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill7657" title="python 查询技能"><img
src="https://img.php.cn/upload/skill/000/000/081/179161384046229.jpg" alt="python 查询技能" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill7657" title="python 查询技能" class="overflowclass">python 查询技能</a>
<p class="overflowclass">查询客流数据，输出JSON格式，可直接导入Bitable等可视化工具</p>
</div>
<a rel="nofollow" href="/xiazai/skill7657" title="python 查询技能" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
- 禁止用
Product.objects.filter(id=product_id).update(stock=F('stock') - quantity)：它绕过 Python 层校验，可能扣成负数 - 如果业务允许“预占库存”，可拆成两步：先
select_for_update+ 标记为“已预占”，再异步确认；但核心锁逻辑不变 - Django 5.0 对 SQLite 的
select_for_update()有警告（不支持），生产环境务必用 PostgreSQL 或 MySQL
并发测试时为什么本地跑不出超卖？
因为默认开发服务器（runserver）是单线程，或你用 locust/pytest-asyncio 模拟并发时没真正触发数据库连接竞争。
- 必须用多进程/多线程真实发起 HTTP 请求（如
ab -n 100 -c 20或hey -n 100 -c 20） - 数据库连接池要足够大（如
CONN_MAX_AGE=0或MAX_CONNS≥ 并发数），否则连接排队掩盖了锁竞争 - 日志里加
print(f"扣减前 stock={product.stock}")无意义：它发生在锁内，但你看到的只是串行输出；真超卖必须查数据库最终值
乐观锁适合什么场景？
当冲突极少、且业务能接受重试时，可用版本号（version 字段）+ update(..., where=[Q(version=old_version)]) 实现乐观锁。但它不是 Django 5.0 的内置机制，需手动维护。
- 适合低频修改、高读场景（如文章点赞数）；不适合高频库存变更
- 每次失败都要重试整个事务（查库存 → 判断 → 更新），增加延迟和 DB 压力
- Django 没有
update_if_match这类语法糖，得写原生 SQL 或用extra(where=...)，易出错
真正难的不是写对一行 select_for_update()，而是确保所有库存变更入口（管理后台、API、定时任务、Celery 任务）都走同一套锁逻辑——漏掉任意一个，超卖就藏在那里。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
