先说一个核心前提：要彻底阻断 SQL Server 触发器里的递归调用链，必须同时关闭两个控制开关——一个是数据库级的 RECURSIVE_TRIGGERS，另一个是服务器级的 nested triggers。只关闭其中一个，递归依然会发生，等于白费功夫。更危险的操作，是在触发器里更新自己正在监控的那张表——只要逻辑形成闭环，堆栈溢出几乎必然降临，而不是“有可能”溢出。
检查当前递归开关的启用状态
SQL Server 针对递归问题设置了两道独立防线，缺一不可。RECURSIVE_TRIGGERS 是数据库级别的属性，默认处于关闭状态（OFF）；而 nested triggers 是实例级别的配置，默认值为 1，即已启用。即使把数据库级的开关关了，实例级的开关如果还开着，一个 INSERT 动作触发某个 AFTER 触发器，该触发器再往同一张表执行 UPDATE，就会立刻激活另一个 AFTER UPDATE 触发器——递归链就开始压栈，堆栈溢出风险随之而来。
如何确认当前状态？用下面两条命令就能快速定位：
SELECT DATABASEPROPERTYEX(DB_NAME(), 'IsRecursiveTriggersEnabled')—— 返回 1 表示递归触发器处于开启状态EXEC sp_configure 'nested triggers'—— 第二列的值如果是 1，说明嵌套触发器已被启用
真正禁用递归的两步操作
不能只依赖 ALTER DATABASE，也不能只修改 sp_configure，必须两手同时执行：
ALTER DATABASE [your_db] SET RECURSIVE_TRIGGERS OFFEXEC sp_configure 'nested triggers', 0; RECONFIGURE
这里有两个容易被忽视的细节：第一，nested triggers 是实例级别的配置，修改后会影响到所有数据库，而不仅仅是当前库。第二，RECURSIVE_TRIGGERS 是库级配置，切换数据库后需要重新确认其状态。许多人在部署脚本里硬编码了 SET RECURSIVE_TRIGGERS ON，这几乎是遗忘率最高的陷阱，务必警惕。
触发器内更新同表的替代方案
在触发器里对当前表执行 UPDATE 或 INSERT，是通往堆栈溢出的最短路径。能避开就尽量别走这条路：
- 改用
INSTEAD OF触发器，直接接管原始操作，将逻辑收拢，避免“提交后再触发”带来的隐式递归链 - 把状态同步、审计写入这类逻辑提到应用层，由业务代码统一控制执行顺序
- 如果必须在数据库层处理，那就加一道守卫：在触发器开头写上
IF TRIGGER_NESTLEVEL() > 1 RETURN。但请注意，这只是兜底手段，并非设计思路
别指望 TRIGGER_NESTLEVEL() 能判断“是不是自己调自己”——它只统计嵌套层数，不管是不是同一个触发器，也不跨线程感知并发递归。换句话说，它只能告诉你递归发生了，但无法从根本上解决问题。
堆栈溢出的表现非常隐蔽
这个问题（指堆栈溢出）的隐蔽性极高。它不会直接报“堆栈溢出”这种明确的错误，而是出现连接突然中断、SSMS 无响应、日志里冒出 StackOverflowError 或 Event loop exception，与 DBeaver 在解析复杂 SQL 时的崩溃现象极其相似，很容易被误判成客户端或工具的问题。
上线前务必用边界值做一次测试：插入或更新一行数据，然后立刻执行 SELECT TRIGGER_NESTLEVEL()，如果返回的结果是 2 或以上，说明递归链已经开始运转。真正的难点从来不是“怎么关闭递归”，而是识别那些看似无害的间接更新——比如 A 表的触发器去改了 B 表，B 表的触发器又反过来改了 A 表，这种环状依赖比同表自调用更难发现，也更容易埋下隐患。
