SET XACT_ABORT ON是保障事务强一致性的底线开关，开启后运行时错误将终止并回滚整个事务；默认OFF时仅回滚出错语句，其余仍可能提交，导致数据不一致。
必须显式设 SET XACT_ABORT ON，否则“强一致性”只是假象。 它不是锦上添花的配置，而是让事务在出错时真正回滚的底线开关。默认 OFF 下，主键冲突、类型转换失败这类常见错误只会回滚单条语句，其余已执行的 INSERT/UPDATE 依然提交——业务上就变成“用户建了但没绑角色”“订单生成了但没扣库存”。
为什么 SET XACT_ABORT ON 必须放在 BEGIN TRANSACTION 之前
它的作用范围是“当前会话后续所有语句”，不溯及既往。一旦你先写了 BEGIN TRANSACTION，再设 SET XACT_ABORT ON，那开头几条语句已经脱离保护。
-
SET XACT_ABORT ON必须紧贴批处理开头，或至少在BEGIN TRANSACTION前一行 - 动态 SQL（
EXEC()或sp_executesql）会创建新作用域，SET XACT_ABORT不继承——需要在动态语句内部重新设置 - 链接服务器调用（如
INSERT INTO [srv].db.sch.t）也受此规则约束；若漏设，远程操作可能已提交而本地回滚失败
SET XACT_ABORT ON 和 TRY...CATCH 不是二选一
很多人以为加了 TRY...CATCH 就够了，其实不然。某些运行时错误（比如约束冲突 Msg 2627、死锁 Msg 1205）在 XACT_ABORT OFF 时根本不会进入 CATCH 块，而是直接继续执行下一条语句。
- 开了
SET XACT_ABORT ON后，出错会立即将事务置为不可提交状态（XACT_STATE() = -1），这时CATCH才能可靠捕获并做IF XACT_STATE() 0 ROLLBACK - 没开它，
@@ERROR可能非零，但@@TRANCOUNT没变，COMMIT仍可能被执行——数据就脏了 - .NET 的
SqlClient在连接池场景下，若未设该选项，可能抛TransactionAbortedException却不提示具体原因
分布式事务中它不是可选项，而是启动条件
用 BEGIN DISTRIBUTED TRANSACTION 时，SET XACT_ABORT ON 是 DTC（分布式事务协调器）介入的前提。没它，SQL Server 遇到错误只回滚本地语句，DTC 完全不感知，远程数据库早已提交，事务静默降级为多个本地事务。
- 必须在
BEGIN DISTRIBUTED TRANSACTION之前设置，且不能靠存储过程头一次设置就覆盖整个调用链 -
EXEC [linked_srv].db.dbo.sp_name这类调用不参与两阶段提交——只有四部分命名的 DML（如INSERT INTO [srv].db.sch.t）或OPENQUERY封装的语句才真正纳入 DTC 管理 -
OPENDATASOURCE和OPENROWSET彻底游离于事务上下文之外，永远无法保证跨库一致性
真正容易被忽略的点在于：它只对“运行时错误”生效，编译错误（比如语法错、对象不存在）不受影响；而且它不解决并发竞态——两个事务同时判断“记录不存在”，然后都插入，XACT_ABORT 帮不上忙，得靠 UPDLOCK + HOLDLOCK 或唯一索引配合重试逻辑。
