因为事务边界必须覆盖所有数据库写操作，包括service层、信号、级联操作等隐式写入；仅视图加@transaction.atomic会导致内部未受控的save()或update()无法回滚。
为什么 transaction.atomic 不能只加在视图函数上？
因为事务边界必须包裹所有涉及数据库写操作的代码段，而视图里调用的 service 层、信号处理、外键级联操作等都可能触发隐式写入。如果只在视图层加 @transaction.atomic，但内部调用了未受控的 Model.save() 或 QuerySet.update()，一旦中途出错，前面已提交的部分无法回滚。
实操建议：
- 把
transaction.atomic()放在最靠近业务逻辑起点的位置，通常是 service 函数或管理命令的入口，而非仅视图 - 避免在
atomic块内做耗时操作（如 HTTP 请求、文件读写），否则会延长锁持有时间，引发数据库连接池耗尽或死锁 - 不要嵌套使用
atomic——Django 默认开启“保存点模式”，但显式嵌套容易混淆回滚范围；如需部分回滚，应主动用transaction.savepoint()+transaction.savepoint_rollback()
transaction.atomic 遇到 IntegrityError 为什么会自动回滚？
这是 Django 的默认行为：当 atomic 块中抛出未被捕获的数据库异常（如 IntegrityError、OperationalError），Django 会触发隐式回滚，且不会继续执行块内后续语句。但注意，它只对数据库操作生效，对内存中已修改的 Python 对象（如 model 实例字段赋值）不还原。
常见错误现象：
立即学习“Python免费学习笔记（深入）”；
- 你在
atomic块里改了obj.name = "new"，又触发了IntegrityError，虽然数据库没存，但obj.name仍是 "new" —— 这不是事务问题，是 Python 对象状态未重置 - 捕获了异常但没 re-raise，导致事务误判为“成功”，实际后续代码可能基于错误数据继续执行
正确做法是：除非你明确要吞掉异常并手动控制流程，否则不要 try/except 掉 IntegrityError；若必须捕获，请在 except 中显式 raise 或返回明确错误状态。
多数据库场景下 transaction.atomic 怎么指定数据库？
默认只作用于 default 数据库。如果你用了多个数据库（比如读写分离或分库），必须显式传参，否则事务完全无效。
使用场景：
- 向
report_db写日志的同时更新primary_db的订单状态，二者需原子性 - 一个函数同时操作
auth_db和tenant_db，但 Django 不支持跨库事务，此时atomic(using="xxx")只能保单库一致性，跨库需用补偿逻辑或分布式事务方案
参数差异：
-
transaction.atomic(using="report_db")：只锁定report_db -
transaction.atomic()：等价于using="default" - 不支持
using=["db1", "db2"]形式——Django 没有原生多数据库事务支持
异步视图（ASGI）中 transaction.atomic 为什么失效？
Django 3.1+ 的异步视图（async def）不支持同步的 transaction.atomic 装饰器或上下文管理器，直接使用会报 RuntimeError: You cannot use transaction.atomic in an async context.
性能与兼容性影响：
- 试图在 async 视图里用
sync_to_async包裹atomic块，会导致线程切换开销，且无法保证事务跨 await 边界的连续性 - 目前唯一可靠方式是：把数据库操作全部收口到同步函数中，并用
await sync_to_async(your_sync_func)()调用，确保atomic在纯同步上下文中执行 - Django 4.2+ 提供了实验性
transaction.atomic异步变体，但要求数据库后端支持（如 PostgreSQL async driver），且仍需手动配置连接池
容易被忽略的地方是：即使你没写 async def，只要项目启用了 ASGI 并混用了 await（比如调用 aioredis），也得检查所有 DB 操作是否意外落入异步栈——事务边界一旦断开，就只剩“尽力而为”了。
