SQL Server 中嵌套事务只是 @@TRANCOUNT 计数器递增，并非独立事务；内层 ROLLBACK 会清零计数器并终止整个事务，导致外层语句报错中止；应使用 SAVE TRANSACTION + ROLLBACK TO 或应用层独立连接实现局部回滚。
SQL Server 中 BEGIN TRAN 嵌套不等于事务隔离
嵌套事务在 SQL Server 里只是 @@TRANCOUNT 计数器加 1，不是新开一个独立事务上下文。外层事务一旦回滚，所有嵌套层级的数据修改都会被一并撤销——下层过程自己调用 COMMIT 或 ROLLBACK 不会改变这个事实。根本原因在于：SQL Server 没有真正的“子事务”概念，只有“事务计数”和“最外层提交/回滚”两个动作点。
为什么 ROLLBACK TRAN 在内层执行会导致报错
常见错误信息：The transaction ended in the trigger. The batch has been aborted.。这是因为内层存储过程执行了 ROLLBACK TRAN，把 @@TRANCOUNT 直接清零，但外层过程仍以为事务还在进行，后续语句（比如再查一次表、或执行 COMMIT）就会因事务状态不一致而中断。尤其在触发器或嵌套调用链中，这种失衡极易发生。
- 外层过程执行
BEGIN TRAN→@@TRANCOUNT = 1 - 调用内层过程，它也执行
BEGIN TRAN→@@TRANCOUNT = 2 - 内层过程执行
ROLLBACK TRAN→@@TRANCOUNT = 0，且整个事务被标记为“已结束” - 外层过程继续执行，哪怕只是一句
SELECT 1，也会触发批处理中止
想让某段逻辑“不受外层事务影响”，该用什么
不是靠嵌套事务，而是用 SAVE TRANSACTION + ROLLBACK TO，或者更彻底地——改用自治事务（仅限 Oracle）或拆出独立连接（如应用层另起一个数据库连接执行日志写入）。SQL Server 本身不支持自治事务；如果真需要审计日志不被主事务回滚掉，只能：
一款AI工具，主要用于运行或监督单遍 Codex 实现，包含预检门控、分步计划执行及严格的 QA 缺陷闭环。适用于执行已批准的售前...，适合需要提升相关任务效率的用户。
- 把日志写入操作移到主事务之外，比如用 Service Broker、外部队列，或由应用层异步处理
- 使用
SAVE TRANSACTION savepoint_name设保存点，内层出错时只回滚到该点，保留外层可继续提交 - 避免在数据操作型存储过程中自行
BEGIN/COMMIT/ROLLBACK，统一由最外层业务过程控制事务边界
金仓（KingbaseES）兼容版的特殊情况
如果你正从 SQL Server 迁移到 KingbaseES SQL Server 兼容版，要注意：虽然它支持 TRY...CATCH 和 SAVE TRANSACTION，但嵌套事务行为仍与 SQL Server 一致——@@TRANCOUNT 失衡问题同样存在。官方文档明确指出其事务层级和 xact_abort 行为是兼容的，这意味着你不能指望换平台就自动解决嵌套回滚混乱的问题。
事务边界的模糊地带最容易在多人协作维护的老存储过程中暴露出来，尤其是当不同开发者各自封装了“带事务的工具过程”又互相调用时。真正可靠的模式只有一个：事务控制权必须收口到最上层业务过程，其余过程只做数据操作，不碰 TRAN 相关语句。
