sql server触发器中error_*()值易丢失，因其仅在catch块内首次调用有效；必须在catch开头立即用declare存入变量，否则后续调用返回null或0。
SQL Server触发器里ERROR_*()值为什么一不留神就丢了
因为 ERROR_NUMBER()、ERROR_MESSAGE()、ERROR_LINE() 这些函数只在 CATCH 块内有效，且**仅在第一次调用时返回当前错误上下文**。一旦你在 CATCH 里执行了任何其他语句（哪怕只是 SELECT 1），后续再调用这些函数就会返回 NULL 或 0——不是没报错，是值被覆盖了。
- 必须在
CATCH开头第一行就用DECLARE把它们存进变量：DECLARE @err_msg NVARCHAR(4000) = ERROR_MESSAGE(); - 别在
CATCH里写日志前先查表、调函数或做IF判断，这些都可能触发新错误或干扰上下文 - 如果触发器里嵌套了存储过程调用，
ERROR_PROCEDURE()返回的是触发器名，不是内部 SP 名——想定位深层问题得靠ERROR_LINE()和日志打点
日志表插入失败会导致整个事务回滚？怎么防
是的。触发器和主 DML 共享同一事务，INSERT INTO ErrorLog 如果因约束冲突、字段超长或锁超时失败，会连带让原始 INSERT/UPDATE/DELETE 一起回滚——用户看到的是“操作失败”，但根本不知道触发器才是元凶。
- 日志表结构要极简：最少字段（时间、错误号、消息）、无外键、无触发器、主键用
IDENTITY而非GUID - 插入时加
WITH (TABLOCK)避免页锁争用，但高并发场景慎用；更稳妥的是用INSERT ... SELECT+WHERE NOT EXISTS防重复 - 关键防御：插入前加
IF @err_msg IS NOT NULL判断，避免空值插入触发NOT NULL约束失败 - 不要在
CATCH里调用另一个可能出错的存储过程记录日志——那等于把单点故障变成双点故障
为什么RAISERROR不如THROW可靠
RAISERROR 会重置错误号、丢失原始 ERROR_LINE()，且默认严重级为 10（低于事务中断阈值），导致上层业务代码捕获不到——你以为吞掉了错误，其实它还在那儿静默破坏数据一致性。
- 用无参
THROW：它原样重抛原始错误，保留全部上下文（包括行号、过程名、嵌套深度） - 别写
RAISERROR(@err_msg, 16, 1)——这会把ERROR_NUMBER()变成 50000，掩盖真实问题 - 如果必须自定义消息（比如加 trace_id），用
THROW 50000, 'msg', 1，但注意：自定义错误号无法携带原始ERROR_LINE() -
THROW后不能跟任何语句（包括RETURN），否则报语法错
调试时PRINT不显示？怎么让错误透出来
SSMS 默认不显示触发器里的 PRINT，尤其当触发器被事务包裹时，输出会被缓冲甚至丢弃。更糟的是，如果触发器里用了 SET NOCOUNT ON（常见于模板），PRINT 直接失效。
- 临时调试可在触发器开头加
SET NOCOUNT OFF;，但上线前必须删掉 - 用
RAISERROR('debug: %d rows', 0, 1, @@ROWCOUNT) WITH NOWAIT;强制刷出消息——级别 0 不中断执行，WITH NOWAIT绕过缓冲 - 真正可靠的调试方式是往日志表写中间状态：比如在
TRY块开头插一条'start'记录，在关键分支后插'after validation'，这样即使最终失败也能看到走到哪一步 - 别依赖 SSMS 的“消息”窗口——用
sys.dm_exec_trigger_stats查execution_count和failed_execution_count，比肉眼盯输出靠谱得多
PRINT 或日志表建得多漂亮，而取决于你有没有在 CATCH 第一行就把那几个 ERROR_* 函数的值“抓牢”。稍一松手，线索就断了。
