SQL Server触发器中TRY CATCH仅捕获可恢复运行时错误，对编译期错误（如表/列不存在）和终止性错误（如外键、唯一键冲突）无效；必须将全部DML操作置于TRY内，CATCH首行立即捕获ERROR_*信息，日志表需极简设计并隔离事务，回滚前须校验XACT_STATE()与@@TRANCOUNT。
触发器里 TRY CATCH 为什么经常不生效
因为 SQL Server 触发器中 TRY CATCH 只捕获可恢复的运行时错误（如 1/0、CONVERT(INT, 'abc')），对两类错误完全无感：表不存在、列名拼错 这类编译期错误，以及 违反外键约束、唯一键冲突 这类终止性错误。它们会在事务已标记为“不可提交”后直接跳出，CATCH 块根本不会执行。
常见误判场景：
- 在
BEGIN TRY外写了SELECT * FROM nonexistent_table—— 批处理直接报错退出，连 TRY 都没进 - 把 TRY 套在
IF UPDATE(col)分支里，结果错误发生在 IF 外围 —— 不在 TRY 范围内，自然不捕获 - 用
RAISERROR('msg', 10, 1)—— 严重级 10 是信息性消息，不会触发 CATCH
如何写一个真正能落地的异常捕获结构
必须把所有可能出错的 DML 操作包进 BEGIN TRY 和 END TRY 之间，且 CATCH 块要立刻提取上下文并做最小化日志写入。关键不是“全包”，而是“可控范围 + 快速脱身”。
实操要点：
-
BEGIN TRY必须紧接在触发器主体逻辑开头，不能嵌套在IF或循环内部再起 - CATCH 第一行就执行：
DECLARE @err_num INT = ERROR_NUMBER(), @err_msg NVARCHAR(4000) = ERROR_MESSAGE(), @err_line INT = ERROR_LINE()—— 后续任意语句（包括RETURN）都可能覆盖这些值 - 别在 CATCH 里直接
INSERT INTO error_log，先用IF OBJECT_ID('dbo.error_log') IS NOT NULL判定表是否存在 - 日志插入用
INSERT INTO error_log (error_time, error_number, error_message, proc_name) SELECT GETDATE(), @err_num, @err_msg, OBJECT_NAME(@@PROCID)，避开VALUES的隐式类型推导风险
记录日志时 INSERT 失败怎么办
最典型的二次崩溃：触发器报错 → 进 CATCH → 尝试写日志 → error_log 表被锁 / 字段类型不匹配 / 权限不足 → 新错误爆发 → 整个事务中断，原始错误彻底丢失。
可靠方案只有两个方向：
- 日志表设计极简：
id INT IDENTITY、error_time DATETIME2、error_number INT、error_message NVARCHAR(4000)、proc_name NVARCHAR(128)—— 不加索引、不设约束、不关联其他表 - 把日志逻辑抽成独立存储过程，例如
usp_log_error，并在其内部再套一层TRY CATCH；调用时用EXEC usp_log_error @err_num, @err_msg, ...，与主触发器事务隔离
事务回滚前必须检查 XACT_STATE()
进了 CATCH 不代表一定能 ROLLBACK。有些错误（比如主键冲突）会让事务进入 XACT_STATE() = -1（不可提交状态），此时 ROLLBACK TRANSACTION 可以执行；但若事务尚未显式开启（@@TRANCOUNT = 0），直接 ROLLBACK 会报错 The ROLLBACK TRANSACTION request has no corresponding BEGIN TRANSACTION。
安全写法只有一条：
- 在 CATCH 中先判断：
IF XACT_STATE() 0 BEGIN IF @@TRANCOUNT > 0 ROLLBACK TRANSACTION END - 不要依赖“自动回滚”，SQL Server 从不帮你回滚未提交的事务
- 如果触发器逻辑本身没显式
BEGIN TRANSACTION，那@@TRANCOUNT就是 1（触发器自带隐式事务），但XACT_STATE()才是最终判决依据
真正难的不是写 TRY CATCH，而是接受它能力有限：它救不了语法错误，兜不住约束冲突，也压不住连接中断。把日志表做成“哑砖块”，把错误上下文抓得比心跳还快，把回滚判断写得比条件反射还本能——这才是生产环境里最不声张的防御动作。
