开启XACT_ABORT时TRY-CATCH阻止事务回滚的限制及原因

1. 即使开启SET XACT_ABORT ON，TRY-CATCH存在哪些限制会阻止被调用存储过程内的事务回滚？ #

• 致命错误无法被捕获：如果被调用存储过程中发生严重级别≥20的致命错误（如数据库连接中断、系统资源耗尽），SQL Server会直接终止当前会话，此时无论是被调用过程自身还是上层的TRY-CATCH块，都无法执行任何回滚逻辑，事务会被系统标记为孤立状态，无法主动回滚。
• 不可提交事务的处理限制：当被调用过程中的错误导致事务进入不可提交状态（Doomed Transaction）（比如违反主键约束、触发死锁），即使TRY-CATCH捕获到错误，此时只能通过ROLLBACK TRANSACTION回滚整个事务，无法仅回滚嵌套层级的部分操作。如果被调用过程的CATCH块未执行完整回滚（未将@@TRANCOUNT减至0），上层事务会继承这个不可提交状态，若上层没有显式回滚语句，事务将一直处于异常打开状态。
• 嵌套TRY-CATCH的错误传递漏洞：如果被调用存储过程自身包含TRY-CATCH块，但仅捕获错误并抛出，未处理事务回滚，那么上层TRY-CATCH虽然能捕获到抛出的错误，但此时事务仍处于打开状态。由于TRY-CATCH不会自动处理跨层级的事务状态，若上层没有显式回滚，就无法终止该事务。

2. 为何底层存储过程发生错误时，当前存储过程无法执行事务回滚（已开启SET XACT_ABORT ON）？ #

• SET XACT_ABORT ON的生效范围有限：该设置仅对当前批处理中未被捕获的错误生效，会自动终止批处理并回滚事务。但如果底层存储过程的错误被自身的TRY-CATCH捕获，且仅通过RAISERROR或THROW向上抛出，此时上层的SET XACT_ABORT ON不会触发自动回滚——因为错误已被显式处理，不属于“未捕获”的致命错误范畴。
• SQL Server事务的“伪嵌套”特性：SQL Server不存在真正的嵌套事务，BEGIN TRANSACTION只会累加@@TRANCOUNT值，只有当@@TRANCOUNT被减至0时，事务才会真正完成提交或回滚。如果底层存储过程启动了事务（@@TRANCOUNT+1），但错误发生后未执行完整回滚，上层的@@TRANCOUNT仍大于0。此时即使开启SET XACT_ABORT ON，由于错误已被底层处理，上层不会触发自动回滚，若移除了上层CATCH块的回滚语句，就无法将@@TRANCOUNT减至0，事务会持续处于打开状态。
• 不可提交事务的强制要求：若底层错误导致事务进入不可提交状态，SET XACT_ABORT ON也无法自动回滚该事务。这种状态下，事务只能通过显式的ROLLBACK TRANSACTION命令终止，XACT_ABORT的自动回滚逻辑对不可提交事务不生效。

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