xact_state() 是唯一可靠判断事务是否可提交的函数，它返回-1（已损坏）、0（无事务）或1（可安全commit），而@@trancount仅反映嵌套层数，无法识别事务是否实际可提交。

XACT_STATE() 是唯一可靠判断事务是否可提交的函数，不是 @@TRANCOUNT，也不是 @@ERROR —— 它直接告诉你“现在能不能 COMMIT”。

为什么不能只看 @@TRANCOUNT

@@TRANCOUNT 只返回嵌套层数，哪怕事务已被标记为不可提交（比如分布式事务失败后），它仍可能为 1。此时执行 COMMIT TRAN 会报错 Msg 3915：“Cannot commit transaction because it is in aborted state.”

• @@TRANCOUNT = 0 → 肯定没事务，但 = 1 不代表安全
• XACT_STATE() = -1 → 事务已损坏，COMMIT 和 ROLLBACK 都会被拒绝（除了最外层回滚）
• XACT_STATE() = 0 → 没有活动事务，COMMIT 或 ROLLBACK 都会报错
• XACT_STATE() = 1 → 唯一能安全 COMMIT 的状态

TRY...CATCH 中必须用 XACT_STATE() 决定后续动作

在 CATCH 块里，不能默认 ROLLBACK —— 如果事务已处于不可提交状态（XACT_STATE() = -1），显式 ROLLBACK 会成功，但之后再 COMMIT 就彻底失效；而如果事务只是普通错误但仍可提交（XACT_STATE() = 1），盲目 ROLLBACK 就丢掉了重试机会。

• IF XACT_STATE() = 1 BEGIN COMMIT TRAN END
• IF XACT_STATE() = -1 BEGIN ROLLBACK TRAN END
• IF XACT_STATE() = 0 BEGIN /* 无事务，啥也别动 */ END
• 注意：ROLLBACK TRAN 在 XACT_STATE() = -1 时是允许的，且通常是必须做的；但 COMMIT TRAN 在该状态下永远非法

触发器或嵌套调用中，XACT_STATE() 仍反映最外层事务状态

存储过程被触发器调用，或自身又调用了另一个带事务的过程，XACT_STATE() 始终报告整个会话最外层用户事务的状态，不随嵌套深度变化 —— 这正是它比 @@TRANCOUNT 更可信的原因。

• 即使你在过程里写了 SAVE TRANSACTION savepoint_a，XACT_STATE() 也不受影响
• 跨数据库操作、链接服务器查询、sp_getbindtoken 等行为容易触发分布式事务，一旦失败，XACT_STATE() 很快变成 -1
• 不要在触发器里调 COMMIT 或 ROLLBACK —— 触发器没有事务控制权，只能响应状态

最容易被忽略的一点：事务状态是会话级的，不是语句级的。一次失败的插入可能让整个外层事务进入 XACT_STATE() = -1，后续所有语句（包括你认为“无关”的日志写入）都运行在已损坏上下文中 —— 所以检查必须放在每个可能影响事务流的 CATCH 块开头，而不是只在最后统一处理。