触发器无法捕获执行堆栈是数据库内核设计限制，因其作为隐式事件处理器无调用栈帧；SQL Server的ERROR_*函数在触发器中返回NULL，MySQL不提供等价函数，Oracle中会报ORA-06502；定位来源需依赖应用层传参、连接元数据标记或原生审计日志。
触发器本身无法可靠捕获执行堆栈——这不是权限或配置问题，而是数据库内核设计限制。所有主流数据库（MySQL、SQL Server、Oracle）的触发器运行上下文都不包含调用链、客户端堆栈、原始 SQL 文本或应用层调用路径。
为什么 ERROR_PROCEDURE() 和 ERROR_LINE() 在触发器里不工作
这些函数只在 BEGIN TRY...BEGIN CATCH 块中有效，且仅对当前批处理中显式抛出的错误生效。触发器不是“被调用”的过程，而是由 DML 语句隐式激活的事件处理器，它没有调用者栈帧。SQL Server 的 ERROR_*() 系列函数在触发器体中调用会返回 NULL 或空字符串；MySQL 根本不提供等价函数；Oracle 的 DBMS_UTILITY.FORMAT_ERROR_BACKTRACE 在触发器中调用会报 ORA-06502。
-
ERROR_PROCEDURE()只返回当前正在执行的存储过程名，不是触发它的上层逻辑 - 触发器里查
sys.dm_exec_requests或information_schema.PROCESSLIST拿到的是会话级信息，无法关联到具体哪条 INSERT/UPDATE 语句触发了它 - 试图用
sys.dm_exec_sql_text(sql_handle)反查当前语句，在高并发下大概率返回空或上一条已过期的 SQL
真正能定位触发来源的三类实操路径
不要指望触发器“自省”，得靠外部协同或前置埋点：
-
应用层显式传参：在 INSERT/UPDATE 语句中带入业务标识字段，如
INSERT INTO orders (..., triggered_by) VALUES (..., 'payment_service_v2')，再在触发器里读NEW.triggered_by -
连接元数据标记：应用在建连后立即执行
SET SESSION application_name = 'order-api-prod'（PostgreSQL）或SET CONTEXT_INFO 0x5365727669636531（SQL Server），触发器中用APP_NAME()或CONTEXT_INFO()提取 -
数据库原生审计日志：启用 MySQL
audit_log插件（audit_log_policy = ALL）或 Oracle 统一审计（AUDIT INSERT, UPDATE ON schema.table BY ACCESS），审计记录天然含OS_USER、CLIENT_IP、SQL_TEXT、SESSION_ID
误用 TRIGGER_NESTLEVEL() 诊断来源的典型陷阱
这个函数只反映当前触发器是否被其他触发器间接激活（即嵌套深度），和“谁触发了最外层 DML”完全无关。它返回 1 表示顶层触发，2 表示被另一个触发器调用，但不会告诉你那个“另一个触发器”是来自 app-worker-3 还是 DBA 手动执行的脚本。
- 在 SQL Server 中执行
SELECT TRIGGER_NESTLEVEL(), APP_NAME(), HOST_NAME()，你会发现后两者始终是连接池名或 ODBC 驱动名，不是真实服务名 - MySQL 没有等效函数；Oracle 的
ORA_LOGIN_USER返回认证用户，不是发起请求的应用账号 - 依赖
sys.dm_exec_sessions.program_name匹配关键词（如含 “ETL”）来反推来源，极易误判——因为连接池复用后，program_name 是首次建连时设置的，后续所有请求都继承该值
最常被忽略的一点：所谓“触发来源”往往根本不在 SQL 层。比如一个定时任务调用 Python 脚本更新订单状态，脚本里用 SQLAlchemy 执行 session.commit()，此时触发器被激活，但唯一可追溯的只有数据库连接属性。真要定位，得在应用侧打日志、加 trace_id、注入 span context，而不是指望触发器吐出调用堆栈。
