XACT_ABORT ON 是触发器内事务行为的默认且必要设置，显式声明可确保跨环境一致性；THROW 配合 XACT_ABORT ON 能强制回滚整个事务，而 RAISERROR 不能；嵌套事务实际不存在，XACT_ABORT ON 会直接回滚至最外层。
XACT_ABORT ON 是触发器内事务行为的默认且必要设置，不手动设 ON 就可能让错误语句“悄悄失败”，后续语句继续执行，破坏事务原子性。
触发器里 XACT_ABORT 默认就是 ON，但显式写出来更安全
SQL Server 在触发器上下文中默认启用 SET XACT_ABORT ON，这点和普通批处理（默认 OFF）不同。但依赖隐式行为容易出问题——比如你把触发器逻辑剪出来单独调试时，SET XACT_ABORT 状态就变了。
- 显式加上
SET XACT_ABORT ON开头，能确保行为一致，尤其在跨环境部署或单元测试时 - 不要在触发器里用
SET XACT_ABORT OFF，这会削弱错误兜底能力，导致外层事务无法感知内部失败 - 注意：该设置只对当前会话生效，不会影响其他连接，也不继承自调用方批处理
为什么 RAISERROR 不触发自动回滚，而 THROW 可以配合 XACT_ABORT
RAISERROR 抛出错误后，若 XACT_ABORT = OFF（普通批处理默认），SQL Server 通常只回滚出错那条语句，事务继续；而 THROW 在 XACT_ABORT = ON 下能确保整个事务终止——这是新代码应优先选 THROW 的关键原因。
-
RAISERROR是“通知型”错误，不强制中断控制流，即使加了WITH LOG也一样 -
THROW是“中止型”错误，配合XACT_ABORT ON后，错误一发生就终止批处理并回滚事务 - 如果你必须兼容旧逻辑，至少在
RAISERROR后紧跟IF @@TRANCOUNT > 0 ROLLBACK TRANSACTION
嵌套事务 + XACT_ABORT = ON 的实际表现不是“层层回滚”
SQL Server 实际没有真正的嵌套事务，@@TRANCOUNT 只是计数器。XACT_ABORT ON 触发回滚时，它清空的是最外层事务（即 @@TRANCOUNT 归零），而不是逐层退出。
- 即便你在存储过程中用
SAVE TRANSACTION设了保存点，XACT_ABORT ON出错后也不会只回滚到保存点，而是直接全滚 - 想实现局部回滚，得靠
TRY...CATCH+ 显式ROLLBACK TO savepoint_name，且必须确保XACT_ABORT OFF（否则 CATCH 块都进不去） - OLE DB / .NET 客户端（如 SqlClient）在开启
Enlist=true时，强烈要求服务端XACT_ABORT ON，否则可能抛出TransactionAbortedException
检查和切换 XACT_ABORT 状态的可靠方式
不能靠 SELECT @@OPTIONS 直接读值，得用位运算判断——因为 @@OPTIONS 是整型位掩码，XACT_ABORT 对应第 15 位（值为 16384）。
DECLARE @XACT_ABORT VARCHAR(3) = 'OFF'; IF ( (16384 & @@OPTIONS) = 16384 ) SET @XACT_ABORT = 'ON'; SELECT @XACT_ABORT AS XACT_ABORT;
- 在触发器开头加这段检查，可快速定位是否被上游连接重置过该设置
- 动态 SQL 中
SET XACT_ABORT不会跨批次生效，每次 EXEC 都要重新 SET - SQL Server Management Studio 的“查询选项 → 执行 → ANSI → SET XACT_ABORT”只是 SSMS 自己的默认模板，不影响已连会话的实际状态
真正难处理的不是怎么设 ON，而是当业务逻辑分散在多个触发器、存储过程和客户端事务中时，XACT_ABORT 状态可能在某一层被意外关闭，又没配 TRY...CATCH，结果错误被吞掉，数据半途而废——这种静默失败比报错更危险。
