SQL Server触发器中TRY…CATCH可捕获大多数运行时错误，但须在同一批处理内连续书写、不可含GO；ERROR_*函数仅在CATCH内有效；需用THROW/RAISERROR重抛错误才能通知应用；不自动回滚，须手动检查XACT_STATE()并处理；对编译期错误无效。
SQL Server 触发器中不能直接用 TRY…CATCH 捕获所有错误，但只要满足作用域和语法约束，它确实能捕获大多数运行时错误——关键在于必须把整个逻辑包进存储过程式结构里，且不能被 GO 或批处理打断。
触发器内 TRY…CATCH 必须写在同一个批处理中
触发器本身就是一个独立批处理单元，BEGIN TRY 和 BEGIN CATCH 必须连续出现，中间不能有 GO、不能跨批、也不能放在动态 SQL 字符串里执行。一旦出现 GO（比如调试时习惯性加的），SQL Server 就会报错：Incorrect syntax near the keyword 'CATCH'。
-
GO不是 T-SQL 语句，而是客户端工具（如 SSMS）识别的批处理分隔符，它会让TRY和CATCH被拆到两个批里，直接失效 - 触发器定义体（
CREATE TRIGGER … AS后面的内容）天然就是一个完整批，无需也不该加GO - 如果想在触发器里调用外部逻辑，应封装成存储过程再
EXEC，而不是把TRY…CATCH拆出去
ERROR_*() 函数只能在 CATCH 块内调用
像 ERROR_NUMBER()、ERROR_MESSAGE()、ERROR_SEVERITY() 这类函数，离开 CATCH 块就返回 NULL。很多人误以为可以在 TRY 块末尾或触发器结尾处“补查”错误，结果全为空值。
- 必须在
BEGIN CATCH … END CATCH内部立即调用，例如SELECT ERROR_NUMBER(), ERROR_MESSAGE(); - 这些函数不保存历史状态，每个
CATCH只反映当前被捕获的那一次错误 - 若需记录多条错误，得靠
INSERT INTO error_log显式落库，不能依赖函数缓存
触发器中错误默认不传给应用程序
即使 CATCH 成功捕获了错误，调用方（比如应用层的 SqlCommand.ExecuteNonQuery()）仍然收不到异常——因为 SQL Server 把错误“吞掉”了。除非你主动抛出。
- 要用
THROW（SQL Server 2012+）或RAISERROR重新抛出，才能让上层感知失败 -
THROW更简洁：THROW;（重抛原错误）或THROW 50000, '自定义消息', 1; - 用
RAISERROR时注意级别：低于 11 的错误不会中断执行，等于白写；推荐用 16 - 别只靠
PRINT或SELECT输出，它们只是返回结果集，不触发异常传播
事务上下文与回滚行为要手动控制
触发器运行在隐式事务中（对应 INSERT/UPDATE/DELETE 操作），但 TRY…CATCH 不会自动 ROLLBACK。如果没显式处理，错误后继续执行可能破坏数据一致性。
- 在
CATCH块开头先检查事务状态：IF XACT_STATE() 0 ROLLBACK TRANSACTION; -
XACT_STATE()返回 -1 表示不可提交事务（必须回滚），0 表示无活动事务，1 表示可提交 - 不要假设
@@TRANCOUNT > 0就一定该回滚——嵌套事务下它可能为 2，但实际已损坏 - 回滚后若仍想通知应用，必须紧跟
THROW，否则错误静默丢失
最易被忽略的一点：触发器里的 TRY…CATCH 对编译期错误（比如表不存在、列名拼错）完全无效——这类错误在执行前就被拦截，根本进不了 TRY 块。只有运行时错误（如除零、违反约束、死锁）才会触发 CATCH。上线前务必用真实数据路径做 DML 测试，不能只看语法是否通过。
