SQL Server触发器内错误默认不被外层TRY...CATCH捕获，必须在触发器内部显式使用BEGIN TRY/BEGIN CATCH封装逻辑，并用THROW重抛以保留原始错误信息。
SQL Server 触发器里发生的错误，默认不会被外层的 TRY...CATCH 捕获，除非你在触发器内部显式写上 BEGIN TRY / BEGIN CATCH —— 这是很多人踩坑的第一步。
触发器里的错误不会自动向外传播
即使你在调用 INSERT 或 UPDATE 的存储过程中加了 TRY...CATCH，只要错误发生在触发器里，且触发器自身没做异常封装，控制流就会直接中断、事务回滚，但外层 CATCH 什么都收不到。这是因为触发器运行在独立的执行上下文中，且 T-SQL 的 TRY...CATCH 不跨作用域自动传递错误。
- 错误严重性必须 >10 才可能被捕获（比如违反约束、死锁、除零）；语法错误或编译期错误（如引用不存在的列）根本进不了
TRY块 -
INSERT INTO ... SELECT类语句若在触发器中失败，不会触发外层CATCH，除非触发器自己包了TRY...CATCH - 触发器中未提交的事务状态会污染外层事务，容易导致“事务已标记为回滚”这类模糊报错
必须在触发器主体内嵌套 BEGIN TRY / BEGIN CATCH
不能指望外部包裹，必须把整个触发器逻辑（尤其是 DML 操作）放进 TRY 块里，并在 CATCH 中处理。常见写法是：
BEGIN TRIGGER tr_example ON dbo.TableA
AFTER INSERT
AS
BEGIN
BEGIN TRY
-- 核心逻辑：比如 INSERT 到日志表、调用另一个 SP、校验业务规则
INSERT INTO dbo.AuditLog (...) SELECT ... FROM inserted;
END TRY
BEGIN CATCH
-- 必须显式记录错误，否则调用方完全不知道发生了什么
INSERT INTO dbo.ErrorLog (ErrorNumber, ErrorMessage, ErrorTime)
VALUES (ERROR_NUMBER(), ERROR_MESSAGE(), GETDATE());
<pre class='brush:php;toolbar:false;'>-- 若需让上层感知失败，用 THROW 重新抛出（不带参数即可）
THROW;END CATCH END
-
THROW在CATCH中无参使用，等价于原错误重抛，保留原始行号和错误号 - 避免只用
RAISERROR，它会重置错误号、丢失原始上下文，且默认严重级可能低于 11，导致外层捕获失效 - 不要在
CATCH里做复杂逻辑（如再调用另一个可能出错的 SP），否则新错误可能被吞掉
注意 TRY...CATCH 在触发器中的限制
触发器不是普通批处理，很多你以为能用的结构在这里会报错或行为异常：
-
TRY...CATCH不能跨IF块 —— 比如把BEGIN TRY放在IF @flag = 1里面，END TRY放在外面，SQL Server 直接拒绝编译 - 不能在触发器中用
RETURN跳出CATCH后还继续执行后续语句；一旦进入CATCH，执行完END CATCH就结束触发器，后续代码不运行 - 嵌套
TRY...CATCH是允许的，但深度超过两层后调试难度陡增，建议优先拆分逻辑到带错误处理的存储过程里 - 事务状态检查必须手动做：
IF XACT_STATE() 0 ROLLBACK TRANSACTION，因为触发器里ROLLBACK可能影响外层事务一致性
最常被忽略的一点：触发器里 THROW 抛出的错误，如果上层没有对应 TRY...CATCH，会直接终止整个批处理 —— 所以业务代码调用涉及触发器的 DML 时，也得自己包一层 TRY...CATCH，不能只靠触发器单方面兜底。
