transaction.atomic不是“加个装饰器就万事大吉”，因为它本质是嵌套上下文管理器，需显式控制事务边界；异常被静默捕获、跨库操作未指定using、手动commit/rollback、混入非orm操作或测试框架干扰，均会导致部分写入成功。
为什么transaction.atomic不是“加个装饰器就万事大吉”
直接套用 @transaction.atomic 装饰器，但数据库仍出现部分写入成功、部分失败的情况——这是最常见的误用。根本原因在于：Django 的事务边界受数据库引擎、连接配置和异常捕获方式共同影响。transaction.atomic 只保证其作用域内语句在**同一个数据库连接**上执行，并在退出时统一提交或回滚；一旦中间触发了非预期的 commit（比如手动调用 connection.commit()）、切换了数据库别名、或异常被 silent 吞掉（如空 except:），事务就会提前结束。
实操建议：
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
- 确认当前操作使用的数据库后端支持事务（SQLite 默认支持，MySQL 需用 InnoDB 引擎，MyISAM 不行）
- 避免在
atomic块内显式调用connection.commit()或connection.rollback() - 不要用裸
except:捕获异常——至少记录日志，否则事务会静默提交 - 若使用多数据库，必须显式指定
using='db_name'，否则默认只作用于default
transaction.atomic 嵌套时的提交行为怎么理解
嵌套多个 atomic 块时，外层才是真正的事务控制点，内层只是“保存点（savepoint）”。也就是说：只有最外层 atomic 块退出时才决定最终提交或回滚；内层抛出异常只会触发回滚到对应保存点，不影响外层逻辑。
常见错误现象：在内层 atomic 中捕获异常并吞掉，误以为“这段失败了但不影响整体”，结果外层继续执行并最终提交——导致脏数据残留。
实操建议：
- 嵌套使用时，除非明确需要局部回滚（如批量导入中单条失败不中断整体），否则尽量扁平化，用一个
atomic包裹全部相关操作 - 若必须嵌套，确保内层异常能正确传播出去，或显式调用
raise重新抛出 - 注意：MySQL 在 savepoint 回滚后，自增 ID 仍会递进，不会复用——这不是 bug，是引擎行为
跨模型 save() 和 raw SQL 混用时事务还可靠吗
可靠，但前提是所有操作都落在同一个数据库连接里。Django 默认对每个请求复用连接，所以 Model.save()、QuerySet.update()、connection.cursor().execute() 在同一 atomic 块中天然共处一个事务。但有两个关键例外：
实操建议：
- 避免在事务块中调用第三方库的数据库操作（如直接用
psycopg2.connect()），它们会新建连接，脱离事务上下文 - 使用
cursor.execute()执行 DDL（如CREATE TABLE）会导致隐式 commit——PostgreSQL 和 MySQL 均如此，事务立即终止 - 如果必须执行 DDL，应放在事务之外，或改用 Django migration 管理
- 注意
bulk_create()在 PostgreSQL 上默认启用ignore_conflicts=True时可能绕过约束检查，需结合update_conflicts显式控制
测试环境下事务回滚失败的典型原因
Django 测试框架（TestCase）默认为每个 test 方法开启并自动回滚事务，这会与手动写的 atomic 冲突：你写的 atomic 块实际运行在测试事务的 savepoint 内，而测试框架的 rollback 会覆盖它——导致你以为回滚了，其实没生效。
实操建议：
- 单元测试中要验证事务行为，改用
TransactionTestCase，它不依赖 savepoint，而是真实 commit + rollback - 或者，在
TestCase中用with transaction.atomic():手动控制，并 assert 数据库状态（如查表行数、字段值），而非依赖异常是否抛出 - 避免在测试中 mock 数据库操作（如 patch
Model.save），这会让事务逻辑完全失效
atomic 就只是个看起来很安全的装饰器。Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
