必须用@transaction.atomic当一组数据库操作需原子性执行，任一失败则全部回滚；它确保数据一致性，避免脏数据，适用于视图或管理命令，不可用于模型方法或异步视图。
什么时候必须用 @transaction.atomic
当你有一组数据库操作，其中任意一步失败都该让前面所有改动回滚，而不是留下半截脏数据时，就得用它。比如用户注册同时要写 User、Profile、发激活邮件前记日志——只要发邮件失败，前面两个表的插入也得撤销。
- 不加
@transaction.atomic，Django 默认每个 ORM 调用自动提交（AUTOCOMMIT=True），出错就真出错了，没法撤 - 只在视图函数或管理命令里加，别塞进模型方法里——模型层不该承担事务边界职责
- 嵌套使用会触发保存点（savepoint），不是新开事务；外层失败，内层 savepoint 也会一起回滚
@transaction.atomic 和 transaction.atomic() 的区别
前者是装饰器，后者是上下文管理器。行为一致，但适用场景不同：装饰器适合整个函数逻辑都该原子化；上下文管理器适合只包住某几行敏感操作，比如在循环里逐条处理并保证单条失败不影响其余。
- 装饰器写法：
@transaction.atomic放在函数定义上方，作用于整个函数体 - 上下文写法：
with transaction.atomic():包住具体代码块，更灵活，也更容易被误缩进导致范围错误 - 两者都不能跨线程生效——多线程里各自开各自的事务，别指望一个
@transaction.atomic能锁住全局
常见报错和踩坑点
最典型的是 TransactionManagementError: You can't execute queries until the end of the 'atomic' block，基本等于你在事务里调了 commit() 或 rollback() 手动干预了——Django 的 @transaction.atomic 不允许手动提交。
- 别在
@transaction.atomic块里调connection.commit()或connection.rollback() - MySQL 下如果用了
READ COMMITTED隔离级别，可能遇到“幻读”，不是装饰器问题，是隔离级别本身限制 - PostgreSQL 中若在事务里执行了 DDL（如
ALTER TABLE），会直接报错中断事务，因为 DDL 在 PG 里不能在事务块里安全执行 - 异步视图（
async def）里不能直接用@transaction.atomic——它不是 async-safe 的，得换sync_to_async包一层或改用同步视图
性能与边界要注意什么
事务越长，锁持有时间越久，尤其在高并发写入场景下容易拖慢整体响应。不是所有“看起来要一起成功”的操作都值得裹进一个事务。
- HTTP 请求中尽量缩短事务范围——别把 API 响应、日志记录、第三方调用塞进
@transaction.atomic里 - 批量插入用
bulk_create()比循环save()更高效，且仍在同一事务内 - 事务里查不到自己刚
save()但还没提交的数据？那是默认隔离级别导致的，不是 bug；需要立刻读，就显式调refresh_from_db() - SQLite 默认不支持 savepoint，所以嵌套
@transaction.atomic在 SQLite 下实际退化为外层事务，这点容易被忽略
