transaction.atomic 不是简单加装饰器，而是嵌套上下文管理器，需显式控制事务边界、避免跨函数嵌套、隔离非ORM操作、注意多库限制、隔离级别与性能权衡。
transaction.atomic 为什么不是“加个装饰器就完事”
transaction.atomic 看起来像开关，但实际是嵌套上下文管理器。直接在视图函数上加 @transaction.atomic 装饰器，如果函数里又调用了另一个也带 @transaction.atomic 的函数，外层不会中断内层——而是形成嵌套事务（savepoint），出错时只回滚到最近的 savepoint，不是整个操作。
常见错误现象：IntegrityError 报了，但部分数据已写入数据库；或者测试时手动抛异常，发现某些 create() 操作没被回滚。
- 用
with transaction.atomic():显式包裹真正需要原子性的代码块，范围越小越好 - 避免跨函数传递
transaction.atomic装饰器——把事务边界收束在单个业务逻辑入口（比如一个 API 视图或 service 方法） - 如果必须复用带事务的函数，让它接受一个
using参数，并由外层统一控制事务，而不是各自开事务
Django 中哪些操作会意外跳出 atomic 块
transaction.atomic 只对 Django ORM 操作生效，不捕获 Python 异常以外的失败，也不管外部系统调用。一旦你混入非 ORM 行为，事务一致性就断了。
使用场景：发邮件、调用第三方 HTTP 接口、写本地文件、触发 Celery 任务……这些都在事务提交后才执行，但你可能误以为它们“包含在事务里”。
-
send_mail()或requests.post()放在atomic块里？它们成功与否不影响数据库回滚，反而可能造成状态不一致（比如邮件发了但订单没创建成功） - Celery 任务不能直接在
atomic块里.delay()——任务可能在事务提交前就被消费，拿到的是旧数据；应改用on_commit() - 手动执行原生 SQL（
cursor.execute()）默认不参与atomic，除非显式指定同一连接和事务
多数据库下 transaction.atomic 的陷阱
默认 transaction.atomic() 只作用于 'default' 数据库。如果你用 using='other_db' 指定了库，但后续 ORM 调用没带 using，就会切回 default，导致跨库操作无法原子化。
参数差异：transaction.atomic(using='replica') 不等于 “所有 db 操作都走 replica”，它只是告诉 Django 在这个连接上开启事务；ORM 查询仍按模型的 Meta.db_table 和路由规则走。
- 跨库更新（如同时写
default和log_db）本质上无法用单个atomic保证强一致性，Django 不支持分布式事务 - 真要跨库原子写入，得靠应用层补偿（比如记录操作日志 + 定时校对）或改用消息队列+最终一致性
- 测试时容易忽略：用
TestCase时，Django 自动为每个 test 方法加事务，但TransactionTestCase才真正提交——别在后者里依赖atomic的回滚行为
性能与隔离级别：atomic 不是银弹
transaction.atomic 默认用数据库的 READ COMMITTED 隔离级别，在高并发下可能遇到不可重复读或幻读。想避免，得手动设更高隔离级别，但这会锁表/锁行，拖慢吞吐。
性能影响：长事务会持有锁、阻塞其他写操作，尤其在批量更新或含复杂计算的场景下，很容易成为瓶颈。
- 不要在
atomic块里做耗时操作（比如解析大 CSV、调用慢接口）——把纯 DB 操作抽出来，其他放外面 - 必要时用
select_for_update()显式加锁，但得配合nowait=True防死锁，否则可能卡住整个请求 - PostgreSQL 上可传
isolation_level='serializable'，但冲突时会抛TransactionRollbackError，需重试逻辑——这事儿 Django 不帮你做
事务边界的划定，从来不是贴个 @transaction.atomic 就能闭眼过关的事。它要求你清楚每一行 ORM 调用背后连的是哪个库、是否真在事务里、失败时谁负责兜底。稍一模糊，数据就 quietly 不一致了。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
