SQL Server关闭触发器递归需同时禁用数据库级RECURSIVE_TRIGGERS和实例级nested triggers；仅关其一无效，且INSTEAD OF触发器不参与该控制链，CONTEXT_INFO标记法比TRIGGER_NESTLEVEL更可靠防自引用。
SQL Server 触发器递归执行不能靠单个开关“一键关闭”，必须同时关掉两个层级的机制：数据库级 RECURSIVE_TRIGGERS 和实例级 nested triggers。只关一个，递归仍可能发生。
SQL Server 关闭递归触发器要改两个配置
很多人以为执行 ALTER DATABASE ... SET RECURSIVE_TRIGGERS OFF 就完事了，其实这只是拦住了“直接递归”（比如 INSERT → trg → INSERT 同表），对“间接递归”（INSERT → trg_A → UPDATE B → trg_B → UPDATE A）完全无效。
-
RECURSIVE_TRIGGERS OFF是数据库级设置，只影响当前库，用ALTER DATABASE [db_name] SET RECURSIVE_TRIGGERS OFF -
nested triggers = 0是实例级配置，影响所有数据库，必须用sp_configure+RECONFIGURE：
EXEC sp_configure 'nested triggers', 0; RECONFIGURE;
执行前建议先查当前值：EXEC sp_configure 'nested triggers' —— 返回 1 表示启用，0 才是禁用。
CONTEXT_INFO 比 TRIGGER_NESTLEVEL 更适合防自引用
即使关了上面两个开关，如果触发器被存储过程调用、或涉及视图/UDF，TRIGGER_NESTLEVEL() 可能误判（它把合法嵌套也当递归）。真正可靠的是会话级标记 CONTEXT_INFO：
- 业务 SQL 执行前设标记：
SET CONTEXT_INFO 0x54524947474552（"TRIGGER" 的 ASCII 十六进制） - 触发器开头立即检查：
IF CONTEXT_INFO() = 0x54524947474552 RETURN - 千万别用
CONVERT(VARCHAR, CONTEXT_INFO())做字符串比较——截断或编码差异会导致失效 - 若触发器由存储过程调用，过程结尾必须清空：
SET CONTEXT_INFO 0x0
INSTEAD OF 触发器不走递归控制链
INSTEAD OF 触发器绕过默认的递归检测逻辑，但它不是“替代方案”，而是“重写方案”：你得手动实现原本由 DML 完成的写入逻辑，不能简单复制 AFTER 里的 UPDATE 语句。
- 适用于需要完全接管操作的场景（如视图更新、多表联动写入）
- 它不会触发自身监听表的
AFTER或BEFORE触发器，所以天然规避递归 - 但要注意：如果它内部又去显式
INSERT/UPDATE其他带触发器的表，那些表的触发器仍可能形成新递归链
真正难处理的不是“怎么关”，而是“关了之后业务逻辑是否还成立”——比如级联更新依赖触发器自动同步，关掉后就得挪到应用层或用队列异步补全。标记法（CONTEXT_INFO）比全局开关更可控，但也要求所有入口统一设标、清标，漏一处就可能崩。
