XACT_STATE()返回-1表示事务不可提交，只能回滚；返回0表示无活动事务；返回1表示事务可提交或回滚。CATCH中须先判断XACT_STATE()≠0再执行ROLLBACK。
事务出错时，为什么ROLLBACK不一定生效
直接写 ROLLBACK TRANSACTION 不等于事务就一定回滚成功。SQL Server 的事务状态可能已是“不可提交”（XACT_STATE() 返回 -1），此时强行 COMMIT 会报错，而没检查状态就 ROLLBACK 看似执行了，但若事务早已被系统自动终止（比如遇到严重级 20+ 错误），ROLLBACK 实际无效。必须用 XACT_STATE() 判断当前事务是否还“活着”且可回滚。
-
XACT_STATE() = 1：事务可提交，也允许回滚 -
XACT_STATE() = 0：无活动事务（比如错误发生在 BEGIN TRY 之前，或事务已被系统强制终止） -
XACT_STATE() = -1：事务已进入不可提交状态，只能回滚，不能 COMMIT
所以 CATCH 块里不能无条件 ROLLBACK，得先查状态：
BEGIN CATCH
IF XACT_STATE() <> 0
ROLLBACK TRANSACTION;
-- 后续日志、RAISERROR 等...
END CATCHSET XACT_ABORT ON 是不是必须加
不是必须，但强烈建议开启。它控制事务中单条语句出错后的整体行为：SET XACT_ABORT ON 表示只要任意一条语句失败，整个事务立即标记为不可提交（XACT_STATE() 变为 -1），后续语句不再执行；而默认 OFF 时，错误语句回滚，其余语句照常运行——这极易导致数据不一致，比如转账扣款成功但入账失败，还继续执行了发通知逻辑。
注意：XACT_ABORT 不影响 TRY/CATCH 是否触发，只影响事务生命周期。它和 TRY/CATCH 是互补关系，不是替代关系。
CATCH 块里该用 RAISERROR 还是 THROW
优先用 THROW（SQL Server 2012+）。它原样重抛原始错误，包括行号、过程名、严重级，客户端能拿到完整上下文；而 RAISERROR(@msg, 16, 1) 会丢失原始错误号、行号和过程名，变成新错误，调试困难。
但 THROW 有两个硬限制：
- 不能在 CATCH 块外使用
- 不能用于重抛自定义消息（比如想加前缀日志），必须配合
RAISERROR或拼接后THROW 50000, @newmsg, 1
兼容旧版本（2005–2008R2）只能用 RAISERROR，记得设严重级 16（11–18 可被捕获，16 是通用用户错误推荐值）。
为什么 SET NOCOUNT ON 在存储过程中几乎必加
不加会导致每个 INSERT/UPDATE/DELETE 后返回 “(1 row affected)” 消息，这些额外结果集会干扰客户端（尤其是 .NET SqlCommand 或 Delphi ADO）对错误的捕获——异常发生时，客户端可能先收到空的结果集，再收到错误，最终漏掉异常。加了 SET NOCOUNT ON 后，只有显式 SELECT 或 RAISERROR/THROW 才产生输出，错误传递路径干净。
顺带一提：SET NOCOUNT ON 对性能也有轻微提升，减少网络包数量，尤其在循环批量操作中更明显。
真正容易被忽略的是：事务状态判断和错误重抛方式的选择——它们不写不会报语法错，但一旦线上出问题，日志里看不到原始错误行号，回滚又没生效，排查就会卡在“到底哪条语句坏了”和“为什么数据还是脏的”上。
