TRIGGER_NESTLEVEL() 返回当前触发器在触发器调用链中的嵌套深度，仅统计DML直接或间接激活的触发器层数；例如INSERT→trg_A→UPDATE→trg_B→UPDATE→trg_A重入时值为2。
TRIGGER_NESTLEVEL() 返回值到底代表什么
TRIGGER_NESTLEVEL() 返回的是当前触发器在**整个触发器调用链中的嵌套深度**，不是会话级总嵌套（@@NESTLEVEL 那种），也不是存储过程或函数的层数。它只统计由 DML 语句直接或间接激活的触发器数量。比如：INSERT → trg_A → UPDATE另一张表 → trg_B → 再次UPDATE原表 → trg_A被重入，此时 TRIGGER_NESTLEVEL() 就是 2（首次为 1，重入为 2）。
为什么只检查 TRIGGER_NESTLEVEL() > 1 就够了
绝大多数递归死锁都源于触发器对自身所属表的“自我更新”——即 AFTER 触发器里又执行了 UPDATE/INSERT/DELETE 同一张表。这种场景下，第二次进入时 TRIGGER_NESTLEVEL() 必然 ≥ 2。所以防护逻辑只需在触发器开头加一行：
IF TRIGGER_NESTLEVEL(OBJECT_ID(N'dbo.trg_Orders_Update')) > 1 RETURN;
注意必须传入触发器对象 ID，否则默认查当前作用域所有触发器，结果不可靠。常见错误包括：
- 写成
TRIGGER_NESTLEVEL('trg_Orders_Update')—— 字符串不解析为对象 ID，返回 0 - 漏掉
OBJECT_ID()或拼错 schema（如写成dbo.trg_orders_update但实际是sales.trg_Orders_Update） - 在
INSTEAD OF触发器里误用——该类型不参与RECURSIVE_TRIGGERS控制，TRIGGER_NESTLEVEL()仍有效，但逻辑需单独验证
TRIGGER_NESTLEVEL() 和 RECURSIVE_TRIGGERS 设置的关系
TRIGGER_NESTLEVEL() 的值不受 RECURSIVE_TRIGGERS 数据库选项影响——无论你设为 ON 还是 OFF，它都如实反映当前已发生的嵌套层数。也就是说：
-
RECURSIVE_TRIGGERS OFF是“事前拦截”，阻止第二层触发器启动，此时TRIGGER_NESTLEVEL()永远不会超过 1 -
TRIGGER_NESTLEVEL() > 1是“事中短路”，允许触发器启动，但在执行体内部判断并退出，更细粒度、不影响其他表的跨表触发链 - 两者可共存：数据库设为 OFF 作为兜底，触发器内再加
TRIGGER_NESTLEVEL()防护，应对可能的配置遗漏或临时开启
容易被忽略的边界情况
真正出问题的往往不是直白的“自己改自己”，而是隐式触发：
- 触发器里调用了一个存储过程，该过程内部执行了
UPDATE Orders—— 这仍会再次激活trg_Orders_Update，TRIGGER_NESTLEVEL()正确计为 2 - 使用
OPENQUERY或链接服务器更新本地表，某些驱动会绕过RECURSIVE_TRIGGERS限制，但TRIGGER_NESTLEVEL()依然有效 - 触发器里用了视图，而该视图定义中包含对本表的 UPDATE —— SQL Server 在解析阶段就报错，根本到不了
TRIGGER_NESTLEVEL()判断这步
最后一句提醒：别在触发器里依赖 @@TRANCOUNT 做递归控制——它反映的是事务嵌套，和触发器是否重入无关；真正要盯住的，只有 TRIGGER_NESTLEVEL() 和你写的那行 RETURN。
