select_for_update()是库存扣减的起点，因其通过数据库行锁确保并发下“查-判-改”串行执行，但必须在transaction.atomic()中调用、配合索引查询、锁内二次校验库存，并与Redis初筛及定期对账协同使用。
为什么 select_for_update() 是库存扣减的起点
直接用 save() 或 update() 修改库存字段，在并发请求下必然出现超卖。根本原因是读-改-写不是原子操作：两个请求同时读到库存为 1，都判断“够扣”，然后都写回 0，实际卖出了 2 件。
select_for_update() 能在数据库层面加行锁，确保同一行库存记录在同一时刻只被一个事务修改。但它必须配合事务使用，且只在支持行锁的数据库（如 PostgreSQL、MySQL InnoDB）中有效。
- 必须在
transaction.atomic()块内调用，否则锁会立即释放 - 不能在
get_or_404()或普通get()后再调用 —— 必须用select_for_update()替代原始查询，例如：Product.objects.select_for_update().get(id=product_id) - 如果查询条件不命中索引（比如用
name__icontains），MySQL 可能升级为表锁，严重拖慢性能
库存扣减逻辑必须包含显式校验与失败退出
加锁只是第一步，拿到锁后仍需重新检查库存是否充足 —— 因为锁只保证“串行执行”，不保证“条件成立”。比如请求 A 拿到锁但耗时过长，期间库存已被其他事务清零，A 醒来后若不校验就直接扣减，照样超卖。
正确做法是在锁内做“查+判+改”三步，并在不满足条件时主动抛出异常或返回错误，让外层事务回滚。
立即学习“Python免费学习笔记（深入）”；
- 不要写成：
if product.stock > 0: product.stock -= 1; product.save()—— 这里stock是旧值，可能已过期 - 应该写成：
if product.stock ，然后才执行 <code>product.stock -= quantity - 推荐用
F()表达式避免竞态：例如Product.objects.filter(id=product_id, stock__gte=quantity).update(stock=F('stock') - quantity)，但注意它不触发模型save()方法，也不走信号，且返回值是影响行数（0 表示扣减失败）
Redis + Lua 脚本适合做前置秒杀拦截
当并发量极高（比如万级 QPS 秒杀），全量走 Django ORM + 数据库行锁会压垮 DB。这时需要在数据库之前加一层轻量、快速的库存校验，Redis 是常见选择。
关键点是：校验和扣减必须原子，不能拆成 GET + DECR 两步。必须用 Lua 脚本封装，由 Redis 单线程保证原子性。
- 脚本示例（保存为
decr_stock.lua）：if redis.call("GET", KEYS[1]) >= tonumber(ARGV[1]) then return redis.call("DECRBY", KEYS[1], ARGV[1]) else return -1 end - Django 中调用：
result = redis_client.eval(lua_script, 1, "product:123", "1")；若result == -1，直接拒绝下单，不进数据库事务 - 注意 Redis 和 DB 库存要定期对账（比如定时任务比对），因为网络分区或服务崩溃可能导致两者不一致
事务隔离级别与连接池配置会影响锁行为
即使用了 select_for_update()，在 MySQL 默认的 REPEATABLE READ 隔离级别下，若查询条件未命中索引，可能触发间隙锁（gap lock），导致无关记录也被锁住，引发意外阻塞。
此外，Django 的数据库连接默认不复用，高并发下容易打满连接数，使锁等待堆积，最终超时失败。
- 确认库存字段有索引：至少是
db_index=True，主键查询最安全 - MySQL 可临时设为
READ COMMITTED减少间隙锁范围（需评估业务是否允许不可重复读） - 调整
CONN_MAX_AGE和连接池大小（如用django-db-geventpool），避免频繁建连放大锁等待时间 -
select_for_update()支持nowait=True或skip_locked=True（PostgreSQL ≥9.5 / MySQL ≥8.0），可避免长时间阻塞，改用快速失败策略
实际落地时，Redis 拦截和数据库行锁不是二选一，而是分层协作：Redis 做毫秒级初筛，DB 做最终一致性保障。最容易被忽略的是对账机制和锁等待超时配置 —— 没有超时的 select_for_update() 在异常场景下会让请求无限挂起。
