SQL Server 无内置函数可靠判断当前是否在触发器中执行；@@NESTLEVEL等指标不专属触发器，TRIGGER_NESTLEVEL需传参且仍无法识别调用源，唯一可控方式是调用方主动透传上下文（如SESSION_CONTEXT）。
SQL Server 没有内置函数或系统变量能可靠判断“当前会话是否正在执行触发器”。 你无法在任意 T-SQL 批处理中写一句 IF IS_IN_TRIGGER() ... 就得到准确结果。所有常见尝试（如查 @@NESTLEVEL、OBJECT_NAME(@@PROCID)、sys.dm_exec_input_buffer）要么不可用、要么权限受限、要么语义错配。
为什么 @@NESTLEVEL > 1 不是可靠指标
很多人误以为“触发器一定在嵌套层级 2 或以上”，于是用 IF @@NESTLEVEL > 1 做判断。但这是危险的：
-
@@NESTLEVEL统计的是所有嵌套调用层级：存储过程里调用另一个存储过程、UDF 里执行 SELECT、甚至动态 SQLEXEC('SELECT 1')都会抬高它 - 一个普通存储过程执行
INSERT INTO Orders，该语句触发的触发器看到的@@NESTLEVEL就已经是 3（连接 → 存储过程 → INSERT → 触发器），和“纯用户直连执行 INSERT”触发的触发器值一样 - SQL Server 允许禁用嵌套触发器（
sp_configure 'nested triggers', 0），此时即使逻辑上存在嵌套，@@NESTLEVEL也不会体现，但你的判断逻辑却还按“有嵌套”跑 - 触发器内调用
sp_who2或查询sys.dm_exec_sessions看不到调用栈，也拿不到发起者对象名
触发器内部能拿到什么上下文信息
真正可用的只有几个只读变量，它们描述“触发器正在响应什么”，而非“谁把我叫醒”：
-
TRIGGER_NESTLEVEL()：返回当前会话中**指定触发器名**的嵌套深度，但必须传入触发器名；不传参时返回所有触发器总嵌套数——仍无法区分来源 -
OBJECT_NAME(@@PROCID)在触发器里返回NULL，因为触发器不是“过程” -
EVENTDATA()只对 DDL 触发器有效，DML 触发器里为空 -
CONTEXT_INFO和SESSION_CONTEXT是唯一可控出口：需由调用方（应用层或存储过程）提前设置，例如在业务逻辑开头执行EXEC sp_set_session_context @key = N'in_business_proc', @value = 1，触发器里再查SESSION_CONTEXT(N'in_business_proc')
实际排查时该看什么
如果你的目标是“确认某段逻辑是否在触发器中运行”，不要试图在运行时检测，而应从外部反推：
- 查
sys.dm_exec_requests+sys.dm_exec_sql_text：如果command字段显示为INSERT/UPDATE/DELETE，且sql_text里没有明显业务逻辑（比如没出现usp_update_order），大概率是触发器在干活 - 查
sys.triggers的is_disabled字段：确保你要找的触发器确实处于启用状态（is_disabled = 0），否则它根本不会进 - 观察事务行为：触发器与原语句共处同一事务，若你在触发器里
RAISERROR或ROLLBACK，整个外部操作都会失败——这是最直接的旁证 - 用
DBCC INPUTBUFFER(@spid)查被阻塞会话的原始输入：如果看到的是简单 INSERT/UPDATE，但执行卡住，再结合锁视图发现它正等待某个触发器相关资源（如OBJECT: database_id:xxx:table_id:xxx），基本可锁定
真正的难点不在“怎么查”，而在“查什么才有意义”。SQL Server 故意不暴露调用链，是因为触发器设计本就该是透明的——它属于数据一致性保障层，不是控制流调度层。一旦你发现自己需要频繁判断“是不是在触发器里”，往往说明业务逻辑和数据约束耦合过紧，该考虑把部分规则移到应用层或用 RLS 替代。
