sql server触发器递归必然导致堆栈溢出，需同时禁用数据库级recursive_triggers和实例级nested triggers；单靠任一开关无效，推荐在触发器首行加if trigger_nestlevel()>1 return守卫，或改用instead of触发器/应用层控制。
SQL触发器里的递归调用不是“可能”导致堆栈溢出，而是只要满足条件就必然崩溃——它不等数据量变大，不看服务器负载，只要触发器链形成闭环，约100层后线程栈直接耗尽，报StackOverflowError或连接无声中断。
SQL Server 中触发器递归的两个开关必须同时关
很多人只执行ALTER DATABASE [db] SET RECURSIVE_TRIGGERS OFF，以为万事大吉。但RECURSIVE_TRIGGERS只是数据库级“门牌”，真正控制底层压栈闸门的是实例级配置nested triggers，默认值为1（启用）。
- 查当前状态：
SELECT DATABASEPROPERTYEX(DB_NAME(), 'IsRecursiveTriggersEnabled')返回1表示库级已开；EXEC sp_configure 'nested triggers'第二列是1表示实例级仍允许嵌套 - 真正禁用需两步并行：
ALTER DATABASE [your_db] SET RECURSIVE_TRIGGERS OFF+EXEC sp_configure 'nested triggers', 0; RECONFIGURE -
RECURSIVE_TRIGGERS随数据库切换而重置，nested triggers影响所有库——漏关任意一个，INSERT → 触发器 → UPDATE same_table → 又触发AFTER UPDATE这种链仍会压栈
AFTER触发器里更新同表是最常见爆栈路径
这不是写法“不优雅”的问题，而是SQL Server运行时机制决定的：它不判断“是不是同一个触发器”，只检查“当前语句是否激活了本表的另一个触发器”。一旦命中，立刻压栈。
- 典型高危代码：
UPDATE orders SET status = 'processed' WHERE id IN (SELECT id FROM inserted)，而orders表上还存在AFTER UPDATE触发器 - 错误现象隐蔽：SSMS卡死、DBeaver报
Can't get column 'is_hidden'、日志出现Event loop exception，容易误判为客户端崩溃 - 验证是否已递归：
SELECT TRIGGER_NESTLEVEL()，插入后立即查，返回值≥2即确认进入递归链
比关开关更可靠的是在触发器开头加守卫
硬关nested triggers会影响所有数据库，若业务真有极少数依赖触发器链的场景（比如遗留审计系统），一刀切会破坏功能。主动防护更可控。
- 在触发器第一行加：
IF TRIGGER_NESTLEVEL() > 1 RETURN——简单有效，跳过深层调用 - 避免用
@@SPID查sys.dm_exec_sessions判断程序名：性能差、不可靠，且无法区分并发中的不同触发路径 - 终极解法不是堵漏洞，而是改设计：优先用
INSTEAD OF触发器接管原始操作，把逻辑收口在一次事务内；次选把DML移到应用层，由业务代码统一控制顺序
真正难的不是“怎么关”，而是识别那些间接递归路径——它们可能藏在视图定义里、跨表外键级联中、甚至默认约束触发的隐式更新里。上线前不做全链路扫描，光靠TRIGGER_NESTLEVEL()守卫，只能拦住明面上的递归，拦不住A表改B表、B表又反向改A表的环状依赖。
