transaction.atomic仅在事务型数据库后端（如PostgreSQL、MySQL InnoDB）生效，SQLite默认支持但易锁表超时，MyISAM引擎下完全无效；需配合select_for_update()防并发竞态，且所有关键读写须在同一atomic块内完成。
transaction.atomic 什么时候真正起作用
它只在数据库层生效，且仅对支持事务的后端（如 PostgreSQL、MySQL InnoDB）有效；SQLite 默认开启，但并发写入时容易因锁表导致超时。如果用的是 MySQL MyISAM 引擎，transaction.atomic 完全不生效——连回滚都做不到。
- 必须确保
DATABASES配置里ENGINE指向事务型后端，比如'django.db.backends.postgresql' - 视图函数里调用
transaction.atomic后，所有 ORM 写操作（save()、delete()、bulk_create()等）才被包裹进同一事务 - 如果中间触发了
connection.commit()或手动执行了原生 SQL 的COMMIT，事务会提前结束，后续操作不在原子范围内
并发扣减库存这类场景，光靠 atomic 不够
transaction.atomic 能防代码逻辑错乱，但挡不住两个请求同时读到“库存=5”，然后各自减 1 写回 4——这是典型的“读-改-写”竞态，需要数据库行级锁配合。
- 必须显式加
select_for_update()，比如Item.objects.select_for_update().get(id=123) - 注意：
select_for_update()只在transaction.atomic块内有效，单独调用会报TransactionManagementError - PostgreSQL 支持
select_for_update(nowait=True)避免阻塞，但会抛DatabaseError，得自己捕获重试 - MySQL 在 READ-COMMITTED 隔离级别下，
select_for_update只锁索引命中行；没索引或范围查询可能锁表
视图里嵌套 atomic 容易踩的坑
多个 transaction.atomic 嵌套时，Django 默认用“保存点（savepoint）”模拟嵌套事务，但底层数据库未必支持——比如 SQLite 不支持 savepoint 回滚到中间状态，出错时整个外层事务都会滚掉。
- 避免在同一个视图里写多层
with transaction.atomic():，尤其不要在外层atomic里再开一个 - 如果真要分段控制，用
transaction.atomic(using='other_db')切换数据库连接，而不是嵌套 - 异步视图（
async def）里不能直接用transaction.atomic，它不是 async-safe 的；得用sync_to_async包一层，但会带来额外延迟 - 日志、缓存更新、HTTP 请求等副作用操作，千万别放在
atomic块里——事务回滚时它们不会撤销，会造成状态不一致
为什么有时候加了 atomic 还出现数据错乱
常见原因是没意识到 Django 的 QuerySet 是惰性求值的。比如 qs = Order.objects.filter(status='pending') 这行不触发查询，但把它放进 atomic 块后，如果后续在别处（比如信号、自定义 manager 方法）又调用了 qs.count() 或 list(qs)，就可能跨事务边界读到旧数据。
立即学习“Python免费学习笔记（深入）”；
- 所有关键读取必须在同一个
atomic块里完成，且用.select_for_update()显式加锁 - 避免在
atomic块里调用其他函数，除非你 100% 确认它内部不触发新查询或不依赖外部状态 - 测试时别只跑单线程，用
concurrent.futures.ThreadPoolExecutor模拟并发请求，否则很难暴露竞态问题
select_for_update() 加索引，或者在 filter 条件里用了非索引字段——这时候锁会升级成表锁，吞掉整个并发能力。 
