触发器无法捕获语句级错误堆栈，因错误发生时触发器可能未执行或已脱离上下文；应优先在存储过程的try...catch中记录完整错误信息，或通过客户端、xevent监控。
SQL Server 里用触发器捕获执行异常？别这么干
直接说结论：INSTEAD OF 或 AFTER 触发器本身**无法捕获语句级错误堆栈**，更没法拿到 ERROR_MESSAGE()、ERROR_LINE() 这类信息——因为错误发生时，触发器可能根本没机会运行，或者已经脱离原始执行上下文。
常见错误现象是：你写了 TRY...CATCH 在触发器里，但插入失败时什么日志都没留下；或者触发器报错后，原语句的错误被掩盖，只看到“触发器执行失败”这种模糊提示。
真正能拿到完整错误堆栈的地方，只有在**调用 SQL 的客户端层**（比如 C# 的 SqlException）或**存储过程内部的 TRY...CATCH 块**中。
想记录 SQL 执行失败，优先用存储过程封装
把 DML 操作包进带 TRY...CATCH 的存储过程中，是目前最可控、最通用的做法。它能访问全部错误函数，还能写入自定义日志表。
使用场景：批量导入、关键业务更新、需要审计失败原因的操作。
-
ERROR_NUMBER()、ERROR_SEVERITY()、ERROR_STATE()、ERROR_PROCEDURE()、ERROR_LINE()、ERROR_MESSAGE()全部可用 - 注意
ERROR_MESSAGE()最大长度是 4000 字符，超长会被截断；如需完整堆栈，得靠客户端捕获Exception.ToString() - 日志表字段建议包含：
error_time、error_number、error_message、procedure_name、line_number、host_name（用HOST_NAME()）、app_name（用APP_NAME()）
示例片段：
CREATE PROCEDURE usp_InsertOrder
@CustomerId INT,
@Amount DECIMAL(18,2)
AS
BEGIN
BEGIN TRY
INSERT INTO Orders (CustomerId, Amount) VALUES (@CustomerId, @Amount);
END TRY
BEGIN CATCH
INSERT INTO ErrorLog (error_time, error_number, error_message, procedure_name, line_number)
VALUES (
GETDATE(),
ERROR_NUMBER(),
ERROR_MESSAGE(),
ERROR_PROCEDURE(),
ERROR_LINE()
);
THROW; -- 重新抛出，不吞掉错误
END CATCH
END
SQL Server 2016+ 可考虑 XEvent 跟踪 SQL 执行失败
如果不想改业务逻辑，又需要无侵入式监控，扩展事件（XEvent）比 SQL Trace 更轻量、更稳定，适合长期开启。
关键点：监听 sqlserver.error_reported 事件，过滤 severity >= 11（排除通知类信息），并勾选 collect_call_stack = 1 获取堆栈。
- 性能影响极小，但启用
collect_call_stack会略增开销，生产环境建议只在问题排查期开启 - 事件数据默认存在内存中，需配置目标（如
event_file）才能持久化；路径必须是 SQL Server 有权限写的本地路径，比如C:\XEvents\errors.xel - 查询日志要用
sys.fn_xe_file_target_read_file()，注意时间范围过滤，否则容易查到海量无关信息
触发器里真要记点什么？只记“发生了什么”，别记“为什么失败”
如果你坚持在触发器里写日志（比如审计谁改了哪条记录），可以记操作行为，但不要试图在触发器里解析失败原因。
原因很简单：触发器运行时，事务可能已回滚，ERROR_*() 函数返回 NULL；而且 AFTER 触发器在语句成功后才触发，根本捕不到失败。
- 安全做法是只记录
INSERTED/DELETED中的主键、操作类型（'INSERT'/'UPDATE'）、SYSTEM_USER、GETDATE() - 避免在触发器里做耗时操作（如远程写日志、调用外部存储过程），否则会拖慢主事务，甚至引发死锁
- 特别注意：触发器嵌套层级默认是 32，递归触发或多个触发器联动时，容易撞上限导致
Maximum stored procedure nesting level exceeded
事情说清了就结束：错误堆栈不在数据库服务端“自动附着”在每条 SQL 上，它只活在具体执行上下文里。离它最近的地方，不是触发器，是你的 TRY...CATCH 块，或者应用代码里的 catch 分支。
