SQL Server中可通过TRIGGER_NESTLEVEL()间接检测：若返回值大于0，说明当前处于任意触发器上下文中；该函数返回嵌套层数，顶层为1，普通批处理中恒为0，且不可用@@NESTLEVEL替代。
SQL Server 中如何检测是否在触发器内执行
SQL Server 没有直接暴露「当前是否在触发器中」的系统函数，但可通过 TRIGGER_NESTLEVEL() 函数间接判断：若返回值大于 0，说明当前执行栈中至少有一个触发器正在运行。
注意这不是「是否在某个特定触发器中」，而是「是否处于任意触发器上下文」——这是 SQL Server 唯一可靠、无副作用的检测方式。
-
TRIGGER_NESTLEVEL()返回当前会话中嵌套触发器的层数；顶层触发器为 1，嵌套触发器递增 - 在普通存储过程或批处理中调用，结果恒为 0
- 它不区分 DML 触发器（
AFTER/INSTEAD OF）或 DDL 触发器，只要激活即计入 - 不能用
@@NESTLEVEL替代——它反映的是所有语句块（如存储过程、EXEC）嵌套深度，与触发器无关
PostgreSQL 中无法可靠检测触发器上下文
PostgreSQL 没有等价于 TRIGGER_NESTLEVEL() 的内置函数，也没有任何官方支持的方式让 PL/pgSQL 函数感知自己是否被触发器调用。
常见误操作是检查 tg_name 或试图读取触发器相关系统变量——这些仅在触发器函数体内部可用，一旦进入被调用的子函数（比如你封装的通用日志函数），上下文信息就丢失了。
- 触发器函数接收的
NEW、OLD、TG_NAME等变量不会自动透传给其他函数 - 试图用
current_setting('app.trigger_context', true)手动标记属于高风险做法：需在每个触发器开头显式设置，且容易漏设或冲突 - 即使通过
pg_backend_pid()+pg_stat_activity查当前活动查询，也无法准确区分「触发器发起的 UPDATE」和「用户直连发起的 UPDATE」
MySQL 中没有安全可靠的检测机制
MySQL 8.0+ 仍不提供任何系统变量或函数来标识当前执行是否源于触发器。所谓「通过 USER() 或 CONNECTION_ID() 推断」纯属误导——它们与触发器上下文完全无关。
唯一能观察到的间接线索是：触发器中的语句在 INFORMATION_SCHEMA.PROCESSLIST 里显示为 Trigger 状态，但这无法在 SQL 运行时被自身读取（会引发元数据锁或循环依赖）。
-
@@session.pseudo_thread_id和@@session.last_insert_id等均不携带触发器标识 - 自定义用户变量（如
@in_trigger := 1）必须由每个触发器手动设置，且无法保证原子性或跨存储过程传递 - 试图在触发器中修改全局变量影响其他会话，违反隔离原则，生产环境禁止使用
跨数据库的务实建议：把检测逻辑下沉到触发器边界
与其在通用函数里费力探测上下文，不如承认一个事实：触发器是特殊执行入口，它的调用者身份本就该由触发器明确声明。
最稳定的做法是在每个触发器第一行，把上下文信息作为参数显式传入后续逻辑——例如调用 log_change(@@PROCID, 'INSERT', 1)，其中第三个参数 1 表示「来自触发器」。
- 避免在函数内部做「我是谁调用的」这类反射式判断，SQL 引擎本身就不鼓励这种模式
- 如果业务要求不同入口走不同分支（比如触发器写日志要跳过某些校验），把这些分支开关提前到触发器定义层，而不是藏在底层函数里
- DDL 触发器、登录触发器等更难统一检测，统一按「入口即契约」设计，反而减少歧义
真正麻烦的从来不是「怎么判断」，而是试图让一段 SQL 同时适配多种执行上下文——这往往意味着职责没切分清楚。
