SQL Server触发器无独立事务，其ROLLBACK会回滚整个外层事务；SET XACT_ABORT ON使错误自动回滚，而ROLLBACK后必须RETURN防止逻辑穿透，且嵌套事务仅是@@TRANCOUNT计数。
触发器运行在主DML的事务上下文中
SQL Server 触发器没有独立事务，它只是主 INSERT/UPDATE/DELETE 语句事务的一部分。一旦触发器执行 ROLLBACK TRANSACTION，回滚的是整个外层事务——不是“触发器自己的事务”，而是那个最初激发它的语句所启动的事务。
这意味着：哪怕你只在触发器里写了一行 ROLLBACK，它也会撤销前面所有已成功执行的语句（包括主DML之前同一批处理里的其他语句），只要它们属于同一个事务。
- 显式事务中（
BEGIN TRANSACTION包裹多条语句）：一次ROLLBACK清空全部修改 - 自动提交模式下（无显式
BEGIN TRANSACTION）：每个语句本应单独提交，但触发器会让隐式事务“延长”到触发器结束；此时ROLLBACK仍只影响当前语句及其触发逻辑，不会波及批中前一条已提交的语句 - 关键区别在于：是否处于同一
@@TRANCOUNT上下文——触发器内ROLLBACK总是把@@TRANCOUNT归零，终止当前事务作用域
SET XACT_ABORT ON 让错误直接终结事务
默认情况下，SQL Server 在触发器中启用 SET XACT_ABORT ON，而普通批处理默认是 OFF。这个设置决定了错误发生后事务是否自动回滚。
当 XACT_ABORT = ON 时，任何运行时错误（比如除零、类型转换失败、THROW）都会立即终止当前批处理，并回滚整个事务；反之，RAISERROR 即使级别够高，也不会自动回滚，必须手动加 ROLLBACK。
-
THROW配合XACT_ABORT ON是最简可靠的组合，错误一抛就滚，无需额外判断 - 显式写
SET XACT_ABORT ON开头，避免把触发器逻辑复制到别处调试时因会话状态不同导致行为不一致 - 不要设
SET XACT_ABORT OFF，否则可能让错误“静默跳过”，后续语句继续执行，破坏数据一致性
ROLLBACK 后批处理不会自动停止
ROLLBACK TRANSACTION 只撤销数据变更，不终止语句执行流。触发器里执行了 ROLLBACK，后续代码仍会继续跑——如果后面还有数据修改操作，那些修改不会被自动回滚。
常见陷阱：在 IF 分支里 ROLLBACK 之后没 RETURN，结果走到下面又插了一条脏数据。
- 务必在
ROLLBACK后紧跟RETURN，防止逻辑穿透 - 不要依赖“回滚后自然退出”，SQL Server 不这么干
- 用
THROW替代RAISERROR+ROLLBACK组合，能天然中断执行流，减少遗漏
嵌套事务只是 @@TRANCOUNT 计数器
SQL Server 没有真正的嵌套事务。所谓“嵌套”，只是 @@TRANCOUNT 加 1；ROLLBACK 总是把它清零，回到最外层起点。
即使你在触发器里写了 SAVE TRANSACTION，XACT_ABORT ON 触发的回滚也不会停在保存点，而是全滚。想做局部回滚，得关掉 XACT_ABORT，再配合 TRY...CATCH 和 ROLLBACK TO savepoint_name。
-
@@TRANCOUNT是唯一可信的状态指标，别信“嵌套事务已提交”这类说法 - 检查
IF @@TRANCOUNT > 0再ROLLBACK，避免在无事务上下文里执行ROLLBACK报错 3903 - 客户端（如 .NET SqlClient）开启
Enlist=true时，服务端必须XACT_ABORT ON，否则可能抛TransactionAbortedException
实际出问题时，往往不是回滚本身太难，而是误以为它只影响触发器内部、或默认就会终止后续代码。最常被忽略的，是 ROLLBACK 后忘了 RETURN，以及把触发器逻辑挪到存储过程里测试时没同步 XACT_ABORT 设置。
