Django单元测试保存模型偶发OperationalError：事务内无法启动事务

这种偶发的OperationalError: cannot start a transaction within a transaction确实让人头大——明明用了Django官方推荐的TransactionTestCase，还在循环场景里随机炸锅，排查起来完全摸不着头绪对吧？我之前也碰到过类似的坑，结合你的场景，给你几个排查和解决的方向：

1. 检查代码中手动开启的事务是否残留 #

虽然TransactionTestCase会帮我们管理测试的事务边界，但如果你的业务逻辑或者测试代码里手动用了transaction.atomic()装饰器/上下文管理器，就可能埋下隐患。比如循环内部的某个操作不小心嵌套了事务，前几次迭代没触发问题，次数多了就因为事务状态混乱报错。

解决方法：

• 梳理所有涉及事务的代码，确保手动开启的事务都正确闭合。比如把业务逻辑里的atomic()调整为只在非测试环境生效，或者在测试方法里显式控制事务边界。
• 可以在循环里加个判断，每次迭代前检查当前是否处于事务中：

  from django.db import transaction
  
  for item in test_dataset:
      # 提前终止可能残留的事务
      if transaction.get_autocommit():
          transaction.abort(transaction.get_connection())
      # 执行你的测试逻辑
      instance = YourModel(...)
      instance.save()
  

2. 重置循环迭代间的数据库连接状态 #

循环过程中，某次操作可能导致数据库连接的事务状态异常（比如意外触发了自动提交，或者连接没有正确释放），后续迭代再执行保存操作时就会触发嵌套事务错误。

解决方法：
在每次循环迭代前后，强制重置数据库连接的事务状态：

from django.db import connection, transaction

for item in test_dataset:
    # 终止当前连接的所有事务
    transaction.abort(connection)
    # 关闭并重建连接（极端情况可用）
    connection.close()
    # 执行测试逻辑
    instance = YourModel(...)
    instance.save()

3. 排查TransactionTestCase的事务特性盲区 #

别以为用了TransactionTestCase就万事大吉——它的事务处理细节可能藏着坑：

• 它会在每个测试方法开始前开启事务，结束后回滚，但如果你的测试用了setUpTestData()，或者有跨测试方法的状态残留，可能导致事务状态混乱。
• 不同数据库引擎对嵌套事务的容忍度不同（比如PostgreSQL比MySQL更严格），偶发问题可能和引擎特性相关。

解决方法：

• 尝试改用TestCase对比测试（它用回滚而非截断来清理数据，事务行为不同），看错误是否还出现。
• 在测试类中重写setUp()和tearDown()，显式清理事务状态：

  from django.test import TransactionTestCase
  from django.db import transaction
  
  class YourTest(TransactionTestCase):
      def setUp(self):
          super().setUp()
          transaction.abort(transaction.get_connection())
      
      def tearDown(self):
          transaction.abort(transaction.get_connection())
          super().tearDown()
  

4. 排查信号或第三方库的隐式事务 #

很多时候问题不是出在自己写的代码里，而是模型的信号（比如pre_save、post_save）或者第三方库偷偷开启了事务，循环多次后触发了嵌套问题。

解决方法：

• 临时注释掉所有信号处理逻辑，或者禁用第三方库的事务相关功能，看错误是否消失，逐步定位触发点。
• 如果是信号里的事务问题，可以把信号中的atomic()调整为non_atomic_requests()（如果是视图相关），或者在测试中临时禁用信号。

最后给个排查小技巧：在测试代码里加日志，每次迭代时记录connection.in_atomic_block()的结果，当错误出现时，就能清楚看到当前是否已经处于事务中，快速定位哪一步触发了嵌套。

内容的提问来源于stack exchange，提问作者Cerin