关 nested triggers 不能解决嵌套层数超限问题，因硬限制32层仍存在且 INSTEAD OF 触发器始终计数；应使用 CONTEXT_INFO() 做会话级守卫，并结合 COLUMNS_UPDATED() 位运算防跨表循环，避免存储过程隐式触发。
为什么直接关 nested triggers 不一定能解决问题
关掉 nested triggers（设为 0）确实能阻止 AFTER 触发器自动激活下游触发器，但它对已存在的调用链无感——当前嵌套深度不会因此降低，32 层硬限制依然存在。更关键的是，INSTEAD OF 触发器始终计入总数，哪怕配置关了也照算不误。你看到“触发器没执行”，大概率是执行到第 32 层时被 SQL Server 熔断（报 Msg 217），而不是被配置拦住。
用 CONTEXT_INFO() 做会话级自调用守卫最可靠
@@NESTLEVEL 不稳定，尤其在视图触发、跨库调用等路径下容易误判；临时表或全局变量又跨会话不可见。真正可控的是会话上下文：
- 业务代码发起 DML 前先打标记：
SET CONTEXT_INFO 0x54524947474552（即 ASCII 的 "TRIGGER"） - 每个触发器开头统一检查：
IF CONTEXT_INFO() = 0x54524947474552 RETURN - 标记值必须用十六进制硬编码，不能依赖
CONVERT(VARBINARY, 'TRIGGER')——不同排序规则可能导致结果不一致
跨表循环怎么防？别只看 UPDATE()，要用 COLUMNS_UPDATED()
UPDATE(col) 只检测 SET 子句是否写了该列名，不关心值是否真变，也完全防不住跨表循环（比如 t1 触发器更新 t2，t2 触发器又更新 t1）。真正有效的判断方式是位运算：
- 用
COLUMNS_UPDATED()获取修改列位图 - 判断第 n 列（索引从 0 开始）是否被改：
IF (COLUMNS_UPDATED() & POWER(2, n)) = POWER(2, n) - 字段顺序一变，位图位置就变——改表结构后必须同步调整 n 的取值
存储过程调用是嵌套高危区，必须做深度守卫
触发器里 EXEC log_proc，而 log_proc 内部有 INSERT INTO audit_log，且 audit_log 上又有触发器？这就 +2 层。常见踩坑点：
- 日志表、审计表这些“安全目标”往往自带触发器，别想当然
- 在存储过程开头加守卫：
IF @@NESTLEVEL > 28 RETURN，留出缓冲空间 - 避免在触发器里调用含 DML 的存储过程；真要调，优先改用异步机制（如 Service Broker）
-
WITH (NOLOCK)不绕过触发器，想避免激活，得把 DML 改成INSERT SELECT FROM ... WITH (READPAST)或干脆移出触发器
实际中最容易被忽略的，是把“禁用嵌套”当成万能解——它只是切断传播路径，但不解决触发器自身逻辑里的自引用、跨表强耦合、或存储过程中隐式触发的问题。盯住每一处 EXEC、INSERT/UPDATE/DELETE 和触发器定义，比反复调 sp_configure 有用得多。
