rollback transaction 会清空整个事务栈而非仅回滚上一步，它将@@trancount归零并撤回所有未提交更改；嵌套事务不真正存在，需用save transaction+rollback to实现局部回滚。
ROLLBACK TRANSACTION 会清空整个事务栈，不是“回滚上一步”
很多人误以为 ROLLBACK TRANSACTION 只撤销最近一次 BEGIN TRANSACTION 的操作，实际它会直接把 @@TRANCOUNT 归零、撤回所有未提交的更改。哪怕你嵌套写了三层 BEGIN TRANSACTION，一个 ROLLBACK TRANSACTION 就全没了——外层逻辑也跟着失效。
典型错误现象：
- 调用含事务的子过程后，主过程报错
Msg 266, Level 16, State 2: Transaction count after EXECUTE indicates a mismatch - 本想只回滚某一步失败的插入，结果连前面成功的更新也丢了
-
COMMIT TRANSACTION报错Transaction count after EXECUTE indicates that a COMMIT or ROLLBACK TRANSACTION statement is missing
根本原因：SQL Server 不支持真正嵌套事务，BEGIN TRANSACTION 只是递增 @@TRANCOUNT，而 ROLLBACK 是“一锅端”。
要用 SAVE TRANSACTION + ROLLBACK TO 实现局部回滚
想保留外层事务状态、只撤回某一段逻辑（比如订单头已插、明细插入失败），必须用保存点。它不改变 @@TRANCOUNT，只标记一个可回退的位置。
实操要点：
-
SAVE TRANSACTION必须在已有事务中执行（即@@TRANCOUNT > 0），否则报Msg 628: Cannot issue SAVE TRANSACTION when there is no active transaction - 保存点名是标识符，不能直接传变量；如需动态命名，得用
EXEC sp_executesql拼接（注意防 SQL 注入） -
ROLLBACK TO savepoint_name后，锁可能释放，但数据仍处于未提交状态（是否可见取决于隔离级别） - 回滚到保存点后，仍可继续
COMMIT TRANSACTION或设新保存点
示例片段：
BEGIN TRY BEGIN TRANSACTION; <p>INSERT INTO Orders (OrderDate) VALUES (GETDATE()); DECLARE @OrderID INT = SCOPE_IDENTITY();</p><p>-- 设保存点，后续失败时只回滚明细，不丢订单头 SAVE TRANSACTION savepoint_orderdetails;</p><p>INSERT INTO OrderDetails (OrderID, ProductID, Qty) VALUES (@OrderID, 101, -5); -- 触发 CHECK 约束失败</p><p>COMMIT TRANSACTION; END TRY BEGIN CATCH IF XACT_STATE() 0 ROLLBACK TO savepoint_orderdetails; THROW; END CATCH</p>
子过程不该自己 BEGIN/COMMIT/ROLLBACK
被调用的存储过程如果擅自开启或结束事务，会破坏调用链的事务一致性。SQL Server 没有自治事务（autonomous transaction）原生支持。
安全做法：
- 子过程只做业务逻辑，通过
RETURN值或OUTPUT参数返回错误信号（如RETURN -1） - 事务控制权始终交给最外层调用者
- 若真要隔离失败逻辑，由外层在调用前设保存点，出错时
ROLLBACK TO它 - 避免在子过程中写
IF @@ERROR 0 ROLLBACK TRANSACTION这类语句
否则极易触发 Msg 266 或事务计数不匹配，尤其在循环调用或嵌套深度不确定时。
别依赖 @@ERROR 判断全部错误
@@ERROR 只捕获上一条语句的错误号，且对严重错误（如对象不存在、语法错误）不生效。它还无法跨作用域传递，容易漏判。
推荐组合：
- 始终搭配
SET XACT_ABORT ON：让运行时错误自动将事务置为不可提交状态，避免部分执行 - 用
BEGIN TRY...BEGIN CATCH捕获所有错误，比轮询@@ERROR更可靠 - 在
CATCH块里用XACT_STATE()判断事务状态：1表示可提交，-1表示必须回滚，0表示已回滚 - 不要在
CATCH里盲目COMMIT，先查XACT_STATE()
复杂点在于：保存点本身不解决死锁或长时间阻塞，它只是回退位置。真正健壮的事务设计，得结合重试逻辑、超时设置和应用层幂等性来兜底。
