SQL Server AFTER触发器自引用递归必然导致卡死，因RECURSIVE_TRIGGERS OFF仅控制跨表嵌套、不约束同表自调用；唯一可靠防护是用CONTEXT_INFO会话标记+TRIGGER_NESTLEVEL兜底。
SQL Server 触发器陷入无限递归，不是“可能出问题”，而是只要在 AFTER 触发器里对本表执行 UPDATE/INSERT/DELETE，且该操作能再次触发同个触发器，就一定会卡死连接、耗尽资源，甚至拖垮实例——RECURSIVE_TRIGGERS OFF 对这种自引用完全无效。
为什么 SET RECURSIVE_TRIGGERS OFF 没用？
这个数据库级开关只控制「不同触发器之间的嵌套调用」（比如 A 表触发器更新 B 表，B 表触发器再更新 C 表），但对「A 表触发器更新 A 表」这种自引用递归毫无约束力。SQL Server 默认允许它，并在每次触发时压栈，约 32 层后直接报 Maximum stored procedure, function, trigger, or view nesting level exceeded (limit 32) 或静默卡死。
-
SELECT DATABASEPROPERTYEX(DB_NAME(), 'IsRecursiveTriggersEnabled')返回1仅说明跨表递归被允许，不反映自引用状态 -
EXEC sp_configure 'nested triggers'查到值为1才是真正底层闸门，但它默认开启，且关掉会影响所有数据库 - 靠
@@NESTLEVEL判断不可靠：它返回的是当前会话所有嵌套对象层级（含存储过程、函数），无法区分“是业务调用还是触发器自调用”
唯一轻量可靠的防护：用 CONTEXT_INFO 做会话级标记
这是 SQL Server 原生支持、无需建表、不依赖临时变量、每个会话隔离的方案。核心思路是：业务代码发起修改前打标，触发器一进来就查标，命中即退出。
- 业务 SQL 执行前必须加：
SET CONTEXT_INFO 0x54524947474552（即"TRIGGER"的 ASCII 十六进制，固定 8 字节） - 触发器第一行必须写：
IF CONTEXT_INFO() = 0x54524947474552 RETURN - 绝对不要用
CONVERT(VARCHAR, CONTEXT_INFO())比较——Unicode 截断、尾部空字节都会导致失效 - 如果触发器由存储过程调用，过程开头设标、结尾清标：
SET CONTEXT_INFO 0x0，否则标记残留会影响后续语句
TRIGGER_NESTLEVEL() 可作为兜底补充判断
它比 @@NESTLEVEL 更精准，只统计当前触发器的嵌套深度。虽然不如 CONTEXT_INFO 主动，但在某些无法控制业务入口的场景（如第三方工具直连）可作第二道防线。
- 在触发器开头加：
IF TRIGGER_NESTLEVEL(OBJECT_ID(N'dbo.YourTriggerName')) > 1 RETURN - 注意必须传入触发器对象 ID，不能只写
TRIGGER_NESTLEVEL()（否则返回全局最大嵌套层） - 不要单独依赖它——如果触发器调用了含 DML 的存储过程，而该过程又间接更新本表，
TRIGGER_NESTLEVEL()仍可能为 1，但实际已递归 - 调试时可用：
SELECT TRIGGER_NESTLEVEL(), CONTEXT_INFO()同时查两者，快速定位是标记漏设还是深度误判
真正容易被忽略的是：标记必须由业务端主动设置，而不是指望数据库自动识别“这次是触发器发起的”。任何试图绕过这一步（比如用临时表存状态、用 UPDATE() 函数过滤字段、或幻想关掉某个开关就能一劳永逸）的方案，在并发、跨连接、存储过程调用等真实场景下都会失效。
