Django默认启用AUTOCOMMIT模式，每条ORM操作独立提交，不加transaction.atomic则无法保证多步操作的原子性；必须显式用装饰器或上下文管理器包裹业务逻辑，否则如转账中扣款成功但入账失败会导致数据不一致。
django.db.transaction.atomic 为什么必须显式使用
不加 atomic，Django 默认每个数据库操作都自动提交（AUTOCOMMIT=True），哪怕你连续调用多个 save() 或 delete()，只要中间出错，前面已执行的不会回滚。比如转账场景中扣款成功但入账失败，钱就丢了。
只有包在 atomic 块里的操作才构成一个事务单元：全部成功或全部撤销。它不是“默认开启”的功能，也不是靠模型层自动感知业务逻辑的——你得亲手圈定范围。
- 装饰器写法适合整个视图函数：
@transaction.atomic - 上下文管理器更灵活，可嵌套、可条件启用：
with transaction.atomic(): - 嵌套时内层抛异常会触发外层回滚，除非外层显式捕获并吞掉异常（不推荐）
save() 失败但数据库已写入？检查是否漏了 atomic 包裹
常见错误是只对部分操作加了 atomic，比如只包了更新语句却忘了创建关联对象。或者误以为 ModelForm.save() 自带事务保障——它没有。
典型翻车现场：
立即学习“Python免费学习笔记（深入）”；
def transfer_money(from_account, to_account, amount):
from_account.balance -= amount
from_account.save() # ← 这里已落库！没被 atomic 包住
to_account.balance += amount
to_account.save()
# 如果第二行报 IntegrityError，第一行扣款无法撤回
正确写法必须把整段逻辑包进去：
from django.db import transaction <p>def transfer_money(from_account, to_account, amount): with transaction.atomic(): from_account.balance -= amount from_account.save() to_account.balance += amount to_account.save()
atomic 嵌套和 savepoint 的实际影响
atomic 支持嵌套，但底层是否真正建 savepoint 取决于数据库后端和参数。PostgreSQL 和 SQLite 支持 savepoint，MySQL（InnoDB）也支持，但若你用的是 MySQL 的 MyISAM 引擎——它根本不支持事务，atomic 会静默失效，连警告都不报。
- 默认
atomic(using=None)使用默认数据库连接；多数据库需显式传using='other_db' -
atomic(savepoint=True)（默认）会在嵌套时建 savepoint；设为False则嵌套块直接复用外层事务，此时内层异常仍导致整体回滚 - 跨线程不能共享同一个
atomic块，每个请求线程需独立开启
异步视图里用 atomic 会报错：async 不兼容同步数据库事务
Django 4.1+ 支持 async view，但 transaction.atomic 是同步阻塞式实现，直接在 async def 里用会抛 SynchronousOnlyOperation 错误。
目前唯一安全做法是把数据库操作收拢进同步函数，再用 sync_to_async 包装：
from asgiref.sync import sync_to_async <p>@sync_to_async def _do_transfer_sync(from_id, to_id, amount): with transaction.atomic(): from_acc = Account.objects.select_for_update().get(id=from_id) to_acc = Account.objects.select_for_update().get(id=to_id) from_acc.balance -= amount to_acc.balance += amount from_acc.save() to_acc.save()</p><p>async def transfer_view(request): await _do_transfer_sync(1, 2, 100)
注意 select_for_update() 也要在同步块里调用，否则锁无效；异步 ORM（如 Django 5.1+ 实验性支持）尚未覆盖所有事务场景。
事务边界的划定永远取决于业务语义，而不是代码缩进或函数粒度。一个 HTTP 请求可能涉及多次数据库交互，但只有明确属于同一业务动作的那些操作，才应该塞进同一个 atomic 块里。多写一层 atomic 不一定更安全，反而可能扩大锁竞争范围或延长事务持有时间。
