唯一可靠防护方式是在触发器开头用 context_info() 做会话级执行标记判断；recursive_triggers 选项和 @@nestlevel 等均无法准确识别自引用死循环，而 context_info() 轻量、会话独享、不跨会话污染。
SQL Server 允许触发器更新自身表，但不会自动阻止它再次触发自己——这不是配置问题，而是设计事实。唯一可靠、生产可用的防护方式，是在触发器开头用 CONTEXT_INFO() 做会话级执行标记判断。
为什么不能依赖 RECURSIVE_TRIGGERS 或 @@NESTLEVEL
RECURSIVE_TRIGGERS 数据库选项对「自引用触发器」完全无效，只控制跨对象嵌套（比如 A 触发 B）。而 @@NESTLEVEL 和 TRIGGER_NESTLEVEL() 都无法区分“合法嵌套”（如视图触发）和“死循环自调用”，数值可能在并发或复杂执行路径下失真。
- 执行
ALTER DATABASE YourDB SET RECURSIVE_TRIGGERS OFF后，UPDATE orders从触发器里发出，仍会再次进入同一触发器 -
TRIGGER_NESTLEVEL()返回值 ≥ 2 只说明“已递归”，但无法确认是否由本触发器发起——可能来自另一个同名触发器或存储过程调用 - 禁用
nested triggers服务器配置虽能兜底，但它是实例级开关，影响所有数据库，且无法按需启用/关闭单个逻辑
用 CONTEXT_INFO() 实现精准跳过
这是 SQL Server 原生支持的轻量会话变量，128 字节二进制，每个连接独享，不跨会话污染，也不受嵌套覆盖。
- 业务代码中，在真正执行 DML 前设标记：
SET CONTEXT_INFO 0x54524947474552（即 "TRIGGER" 的 ASCII 十六进制） - 触发器第一行立即检查：
IF CONTEXT_INFO() = 0x54524947474552 RETURN - 切忌用
CONVERT(VARCHAR, CONTEXT_INFO())比较——可能因 Unicode 截断或空字节提前终止导致失效 - 若触发器由存储过程调用，过程开头设标记，结尾务必清空：
SET CONTEXT_INFO 0x0
哪些替代方案要避开
临时表、全局临时表、@@SPID + 状态表、额外字段标记等，都存在明显缺陷。
- 临时表在触发器内创建后，跨嵌套层级不可见；全局临时表又面临并发写冲突
-
@@SPID在并行执行路径下可能重复，且查sys.dm_exec_sessions性能差、易锁表 - 加字段如
is_processing BIT要改表结构，影响线上业务，且无法保证事务原子性 -
DISABLE TRIGGER+ENABLE TRIGGER是高危操作：DDL 锁阻塞其他请求，且并发场景下一个请求禁用后未启用，另一个已闯入
最常被忽略的一点是：标记必须在业务 SQL 执行前设置，而不是在触发器内部生成。一旦触发器已经运行，再设 CONTEXT_INFO 就晚了——它只能防止下一层递归，不能拦住当前这一轮。连接池复用时尤其要注意，每次获取连接后需重置上下文，否则旧标记残留会导致后续正常语句被跳过。
