SET XACT_ABORT ON是硬性前提，因默认OFF下约束类错误仅回滚单条语句，其余操作仍提交导致数据不一致；必须置于BEGIN TRANSACTION之前才生效，否则事务无法原子回滚。
必须显式写 SET XACT_ABORT ON，且必须放在 BEGIN TRANSACTION 之前，否则事务根本不会原子回滚。
为什么 SET XACT_ABORT ON 不是可选项而是硬性前提
SQL Server 默认 XACT_ABORT 是 OFF，这意味着：单条语句出错（比如主键冲突、类型转换失败），只回滚那一条，其余已执行的 INSERT/UPDATE 仍会提交。典型现象是：Msg 2627, Level 14, State 1 报错后，日志里查得到部分数据已落库，但应用层只看到异常——状态已不一致。
这不是“没写事务”的问题，而是“写了事务但没设开关”，事务形同虚设。
-
SET XACT_ABORT ON的作用不是开启事务，而是让事务具备「错误即终止」能力 - 它对当前会话后续所有语句生效，不能 retroactively 修正前面已执行的语句
- 触发器里默认为
ON，但普通存储过程、ad-hoc 脚本、动态 SQL 都不继承该设置
SET XACT_ABORT ON 必须紧贴存储过程开头
顺序错了就等于没设。常见错误写法：
CREATE PROC usp_InsertUser AS BEGIN BEGIN TRANSACTION; SET XACT_ABORT ON; -- ❌ 太晚！前面没事务保护，且此设置对已开始的事务无效 INSERT INTO Users ...; INSERT INTO Profiles ...; END
正确位置只有一个：在任何 BEGIN TRANSACTION 之前，且最好作为存储过程第一或第二行（SET NOCOUNT ON 可并列）。
- 必须写在
BEGIN TRANSACTION前，否则无法覆盖整个事务块 - 若用
TRY...CATCH，SET XACT_ABORT ON仍是前置条件——某些严重错误（如死锁、约束冲突）根本进不了CATCH块 - 在分布式事务中（
BEGIN DISTRIBUTED TRANSACTION），它更是强制要求，否则 DTC 不介入，远程操作静默提交
光靠 XACT_ABORT ON 还不够：并发重复插入怎么办
SET XACT_ABORT ON 解决的是「出错后能否全回滚」，但它不解决「两个事务同时判断不存在→同时插入」的竞态条件。比如用户注册时检查 username 是否存在，两次请求几乎同时通过检查，然后都执行 INSERT，最终触发主键冲突。
这种场景下，XACT_ABORT ON 只能保证冲突发生后整事务回滚，但无法阻止冲突发生本身。
- 需配合唯一索引（
UNIQUE）+ 重试逻辑，或使用INSERT ... SELECT ... WHERE NOT EXISTS一类原子写法 - 高并发下更可靠的是加锁提示，例如
SELECT ... WITH (UPDLOCK, HOLDLOCK)显式占位 - 不要依赖应用层“先查再插”——数据库才是唯一可信的并发协调者
最容易被忽略的一点：SET XACT_ABORT ON 只对当前批生效。如果存储过程中有 EXEC(@sql) 或调用其他存储过程，那些上下文里还得各自再设一次——它不会穿透动态 SQL 边界。
