django.db.transaction.atomic 能自动回滚，是因为它在进入时开启事务、退出时根据是否抛出未捕获异常（Exception及其子类）决定COMMIT或ROLLBACK；SystemExit等BaseException子类不触发回滚。
django.db.transaction.atomic 为什么能自动回滚
因为 atomic 不是“手动开关事务”的工具，而是 Django 对底层数据库事务的封装：它在进入时开启事务，在退出时根据执行结果决定 COMMIT 还是 ROLLBACK。只要代码块内抛出未被捕获的异常（包括 Exception 及其子类），Django 就会触发回滚——哪怕你没写 try/except。
注意：SystemExit、KeyboardInterrupt 和 BaseException 子类（如 MemoryError）不会触发回滚，这是 Python 异常体系的设计限制。
- 默认行为下，
atomic使用数据库的“最外层事务”语义：嵌套使用时，内层只是保存点（savepoint），不是独立事务 - 如果用
atomic(using='other_db')指定了非默认数据库，必须确保该数据库后端支持事务（比如 SQLite 支持，但某些只读 MySQL 从库可能禁用） - 在视图中直接用
@atomic装饰器时，若视图返回 HTTP 响应前发生异常，Django 中间件会协助完成回滚；但如果在异步视图（async def）里直接用，会报RuntimeError: You cannot use TransactionMiddleware with async views
什么时候必须显式用 savepoint=True
当需要在同一个 atomic 块里“局部失败不连坐”时，比如批量导入数据，某条记录校验失败，但不想让前面已处理的成功项也回滚——这时就得靠保存点。
例如：
立即学习“Python免费学习笔记（深入）”；
from django.db import transaction
<p>with transaction.atomic():
for item in data_list:
try:
with transaction.atomic(): # 内层 atomic 默认创建 savepoint
obj = MyModel.objects.create(**item)
do_something_risky(obj)
except ValidationError:
continue # 这条跳过，不影响其他
except Exception as e:
logger.error(f"Unexpected error on {item}: {e}")
raise # 其他错误仍要中断整个事务
- 内层
atomic的savepoint=True是默认值，可省略；但显式写出更易读 - 不能在
atomic块外调用transaction.savepoint_rollback()，否则报TransactionManagementError: There is no active savepoint - PostgreSQL 对保存点数量无硬限制，但 MySQL 在高并发下频繁建/删 savepoint 可能轻微拖慢性能
常见误用：在 ORM 查询后手动调用 rollback
Django 不提供 transaction.rollback() 这样的手动接口——这不是遗漏，而是设计选择。试图用 connection.cursor().execute('ROLLBACK') 会破坏 atomic 的上下文管理逻辑，导致后续操作抛出 TransactionManagementError: An error occurred in the current transaction. You can't execute queries until the end of the 'atomic' block。
- 想“主动放弃”当前事务？正确做法是抛出异常，比如
raise Exception("abort transaction") - 在测试中想重置数据库状态？别在测试函数里手动 rollback，改用
TestCase的事务隔离机制，或用TransactionTestCase配合reset_sequences=True - 使用
bulk_create时遇到部分失败，默认不回滚整批；若需全批原子性，必须包在atomic里，且确认数据库支持（SQLite 不支持bulk_create的事务内回滚）
信号（signals）在 atomic 块里的执行时机很关键
Django 的 post_save、pre_delete 等信号，在 atomic 块内触发时，并不等同于数据库已提交——它们只是 Python 层回调，发生在事务 commit 之前。这意味着：如果信号处理函数里又修改了模型，这些修改会和原操作一起被提交或回滚；但如果信号里发起 HTTP 请求或写文件，那些副作用无法被事务保护。
- 避免在
post_save里发邮件或调外部 API；真要这么做，得用transaction.on_commit()注册回调 -
on_commit()的回调只在事务成功 commit 后执行，且仅对最外层atomic有效；嵌套 savepoint 的成功不影响它的触发 - 如果
on_commit()回调本身抛异常，Django 不会回滚已提交的事务，只会把错误记到日志里
事务的边界比看起来更依赖代码结构和异常传播路径，尤其在组合使用信号、第三方库或异步任务时，最容易漏掉的是“你以为回滚了，其实没有”的情况。
