set xact_abort on 是生产环境存储过程必需设置，否则事务原子性无法保障，约束类错误将导致部分提交、try...catch 失效及脏数据。
SET XACT_ABORT ON 是必须的，不是可选项
生产环境存储过程中不设 SET XACT_ABORT ON，等于默认放弃事务原子性保障。它不是“可能导致意外终止”的开关，而是“不设就必然导致部分提交”的风险源。很多所谓“意外终止”，其实是错误被静默吞掉、后续语句继续执行造成的脏数据——那才真正意外。
常见错误现象：Msg 2627, Level 14, State 1 主键冲突后，前一条 INSERT 已落库，应用层只看到报错却查不到完整回滚；TRY...CATCH 块完全没触发，因为约束类错误在 XACT_ABORT OFF 下不中断批处理。
-
SET XACT_ABORT ON必须放在BEGIN TRANSACTION之前，且最好紧贴存储过程开头（CREATE PROC或ALTER PROC后第一行） - 不能写在事务内部，否则对已执行语句无效
- 触发器中默认为
ON，但普通存储过程不继承该设置——别靠猜测
为什么加了 TRY…CATCH 还要 XACT_ABORT ON
TRY...CATCH 不是万能兜底：某些运行时错误（如死锁、超时、主键/外键/检查约束冲突）在 XACT_ABORT OFF 下根本不会进入 CATCH 块，而是仅回滚出错语句，后续继续执行。这时 @@TRANCOUNT 可能非零，但事务已处于不可提交状态（XACT_STATE() = -1），你却还在盲目 COMMIT。
- 开启
SET XACT_ABORT ON后，这类错误会立即将事务置为XACT_STATE() = -1，确保CATCH一定能捕获到异常上下文 -
CATCH内必须检查IF XACT_STATE() 0 ROLLBACK，不能无条件ROLLBACK（避免破坏外层事务） - 推荐用本地标志位控制事务生命周期：
DECLARE @TranStarted BIT = 0; IF @@TRANCOUNT = 0 BEGIN BEGIN TRAN; SET @TranStarted = 1; END
RAISERROR 和 THROW 在 XACT_ABORT 下行为不同
如果你在存储过程中用 RAISERROR 主动抛错，SET XACT_ABORT 对它**没有影响**——它不会触发自动回滚或批处理终止。而 THROW 会尊重 SET XACT_ABORT ON 设置，更可靠。
- 新代码一律优先用
THROW，例如：THROW 50001, 'User already exists.', 1; - 老系统混用
RAISERROR时，必须确保SET XACT_ABORT ON已启用，否则RAISERROR报错后事务仍可能继续执行 - 验证当前会话设置：
SELECT CASE WHEN (16384 & @@OPTIONS) = 16384 THEN 'ON' ELSE 'OFF' END AS XACT_ABORT
并发插入重复问题不是 XACT_ABORT 能解决的
SET XACT_ABORT ON 只管“出错后是否全回滚”，不管“两个事务同时判断不存在→同时插入”这种竞态条件。它不提供任何读一致性保障。
- 单纯开
XACT_ABORT无法防止主键冲突，只能让冲突发生后整个事务干净回滚 - 要真正避免重复插入，得配合锁提示，比如在
SELECT检查时加WITH (UPDLOCK, HOLDLOCK) - 或者改用
MERGE语句 + 正确的WHEN NOT MATCHED分支，但要注意MERGE自身的已知 bug 风险
最容易被忽略的一点：XACT_ABORT 的生效范围仅限于当前会话的后续语句，它不修复已经执行过的逻辑。哪怕你把它设在第一行，也不能挽救前面动态拼接 SQL 时漏掉的校验——事务安全从来不是单个开关的事，而是从检查、加锁、修改到提交的整条链路协同结果。
