最常用且有效的两种手段是关闭RECURSIVE_TRIGGERS或在触发器内用TRIGGER_NESTLEVEL()判断；前者硬性阻断所有AFTER触发器递归但影响跨表链路，后者精准防控自我循环且保留必要触发链。
直接关掉 RECURSIVE_TRIGGERS 或在触发器开头加 TRIGGER_NESTLEVEL() 判断，是最常用且有效的两种手段；但选哪一种，取决于你是否允许跨表间接触发链存在。
SQL Server 触发器递归报错的典型现象
执行 INSERT 时卡住不动、连接长时间处于 WAITFOR 或 LCK_M_U 等待状态；或者直接报错：Maximum stored procedure, function, trigger, or view nesting level exceeded (limit 32)。这不是锁超时或死锁检测触发的常规错误，而是 SQL Server 主动中止了嵌套过深的触发链。
根本原因通常是：在 AFTER INSERT 触发器里又对**同一张表**做了 UPDATE（哪怕只改一个字段），导致该 UPDATE 再次激发自身——形成闭环。
禁用数据库级递归开关（硬性阻断）
执行 ALTER DATABASE [YourDB] SET RECURSIVE_TRIGGERS OFF 后，所有 AFTER 触发器的间接递归都会被拦截，INSTEAD OF 不受影响。
- 该设置对新连接立即生效，已有连接需重连才生效
- 它作用于整个数据库，无法按表或触发器单独配置
- 若业务依赖“订单插入 → 更新库存表 → 库存表触发日志写入”这类跨表链路，关掉后链会断裂
-
RECURSIVE_TRIGGERS默认就是OFF，如果你遇到递归问题，大概率是有人手动设为ON过
在触发器内做嵌套深度防护（推荐首选）
比全局开关更精准，适合需要保留部分跨表触发能力、但必须防住自我循环的场景。
在触发器第一行加上：
IF TRIGGER_NESTLEVEL(OBJECT_ID(N'dbo.YourTriggerName')) > 1 RETURN
注意点：
-
TRIGGER_NESTLEVEL()不传参时返回当前会话总嵌套层数；传入具体触发器 ID 可精确判断该触发器是否已激活过 - 不要用
@@NESTLEVEL，它统计的是所有 T-SQL 嵌套（包括存储过程、函数），不专用于触发器 - 如果触发器逻辑涉及临时表或变量缓存状态，记得在
RETURN前清理，避免后续语句误读残留数据
为什么不能靠 TRY…CATCH 捕获递归失败？
TRY…CATCH 对嵌套层级超限错误无效——这个错误发生在语句编译/执行计划生成阶段，早于运行时异常处理机制介入时机。
也就是说，你在触发器里包一层 BEGIN TRY … END TRY BEGIN CATCH … END CATCH，对 nesting level exceeded 完全没用。它只能捕获运行时错误（如除零、类型转换失败、违反约束等）。
真正要防的是递归发生前就掐断，而不是等它爆了再捞。
