sql触发器无法回滚非数据库操作，因为事务机制仅覆盖t-sql数据变更，对文件写入、网络请求、xp_cmdshell、print、raiserror等外部操作不感知、不管理、不可逆。
SQL触发器无法回滚非数据库操作，是因为事务机制只覆盖 T-SQL 语句执行路径内的数据变更，对文件系统、网络请求、外部 API 调用、PRINT 输出、RAISERROR 消息发送等操作，数据库引擎既不感知也不管理其状态——它们压根不在事务上下文中。
触发器里调用 xp_cmdshell 或写文件为什么不能回滚
SQL Server 的 xp_cmdshell、sp_OACreate 或 CLR 外部程序集调用（如 System.IO.File.WriteAllText）属于“扩展过程”或“宿主外执行”，一旦启动就脱离 SQL Server 事务调度器控制。即使后续 ROLLBACK TRANSACTION 成功执行，这些操作已不可逆。
- 例如：
EXEC xp_cmdshell 'echo hello > C:\log.txt'立即落盘，事务回滚对其零影响 -
PRINT 'start'是客户端缓冲输出，不是数据库状态，不会被回滚撤销 - CLR 方法中调用
HttpClient.PostAsync属于异步外部 I/O，SQL Server 不等待也不追踪其完成与否
THROW / RAISERROR 本身不是事务操作，只是信号
RAISERROR 和 THROW 都不修改数据，只是向客户端抛出错误消息。它们不触发回滚，也不隐含事务边界。是否回滚，完全取决于你有没有在抛错前后显式执行 ROLLBACK TRANSACTION，以及连接是否启用了 SET XACT_ABORT ON。
-
RAISERROR('fail', 16, 1)后没跟ROLLBACK→ 上层 INSERT 仍可能提交 -
THROW单独使用时只中断当前批处理，若XACT_ABORT关闭，外层事务照常运行 -
SET XACT_ABORT ON必须在触发器开头设置，且对整个会话有效；放在 TRY 块内无效
触发器嵌套时，ROLLBACK 只作用于最外层事务
触发器运行在父 DML 语句的事务中，没有自己的独立事务。哪怕 A 触发器调用 B 触发器，@@TRANCOUNT 会变成 2，但一次 ROLLBACK TRANSACTION 就直接清空到 0 —— 它回滚的是整个原始 INSERT/UPDATE 的全部变更，而非仅当前触发器涉及的部分。
- 不能靠“局部回滚”来挽救某次子操作失败：SQL Server 不支持保存点（SAVE TRANSACTION）之外的嵌套事务控制
- 如果 B 触发器里写了
ROLLBACK，A 触发器后续逻辑将收到“事务已终止”错误，不能再执行任何数据修改语句 - 日志表写入（如
INSERT INTO audit_log）若发生在ROLLBACK之后，会被一并撤回；若在之前，也一样被撤回——它和主表更新同属一个事务
真正容易被忽略的点是：你以为在触发器里“做了点事”，其实那件事根本不在事务保护范围内。只要操作走出 INSERT/UPDATE/DELETE/SELECT 这个闭环，数据库就撒手不管了。
