Django中transaction.on_commit()在多事务场景下如何匹配关联对应事务

核心逻辑本质：不存在“全局查找匹配事务”的过程 #

很多开发者会误以为on_commit会从全局维护的事务列表里挨个匹配、找到对应要绑定的事务，实际上它根本没有全局查找的环节，从你注册回调的那一刻起，绑定关系就已经定死了。

具体绑定与存储规则 #

• 每个数据库连接独立维护一套自己的事务栈结构，不同连接、不同线程的事务栈完全隔离，不存在跨连接共享的事务状态。
• 每次进入atomic上下文/装饰器块时，会在当前连接的事务栈中压入一个独立的事务帧，这个帧会维护三类内置队列：
  • 提交触发回调队列（即transaction.on_commit注册的内容）
  • 回滚触发回调队列
  • 连接状态标记
• 当你调用transaction.on_commit()时，代码会直接把传入的回调塞到当前连接事务栈的栈顶帧的提交回调队列里，从这一刻开始，这个回调就和当前栈顶的事务帧永久绑定，不会再随调用栈变化移动到其他帧上。

并行事务场景下的隔离保证 #

针对同一应用内多事务并行的场景，绑定逻辑完全不会出现匹配错乱的情况，原因非常简单：

• 同连接的嵌套事务是严格的栈结构：内层事务的回调只存在于内层的栈帧上，和外层事务的回调完全隔离。内层事务回滚时，只会丢弃当前内层帧存储的所有回调，不会影响外层帧上的回调内容；内层事务提交时，只会触发当前帧的回调，执行完成后栈帧弹出，回到外层事务栈的位置。
• 跨连接的并行事务（比如并发请求、多线程任务）：每个连接的事务栈、回调队列都是完全独立的，A连接上注册的回调永远不会被B连接上的事务状态触发，从物理层面就不存在串扰的可能。

回调的触发判定逻辑 #

当某个事务帧走到生命周期终点时，才会根据结果决定是否执行绑定的回调：

• 如果当前事务帧最终执行COMMIT操作（没有被回滚），会在整个事务提交完成、连接回到自动提交状态后，按注册顺序依次执行该帧存储的所有提交回调。
• 如果当前事务帧最终执行ROLLBACK操作，会直接清空该帧存储的所有提交回调，不会触发任何执行逻辑。
• 如果调用on_commit时当前连接根本没有激活的事务（即处于自动提交模式），回调会立刻执行，因为没有需要等待的待提交事务。

举个实际的执行顺序例子：

from django.db import transaction

# 压入外层事务帧（栈顶位置）
with transaction.atomic():
    # 回调存入外层事务帧的提交队列
    transaction.on_commit(lambda: print("外层事务回调执行"))

    # 压入内层事务帧（新的栈顶位置）
    with transaction.atomic():
        # 回调存入内层事务帧的提交队列
        transaction.on_commit(lambda: print("内层事务回调执行"))
    # 内层事务提交，弹出栈帧，立刻触发内层回调
# 外层事务提交，弹出栈帧，触发外层回调

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