sql server中try...catch不自动回滚事务，必须显式执行rollback；它仅捕获严重性>10的运行时错误，不处理语法错误、对象不存在或跨go批处理中断等编译期错误。

TRY...CATCH 在 SQL Server 存储过程中能捕获运行时错误并支持回滚，但它不自动回滚事务，也不捕获编译期错误。你得手动控制事务生命周期，并在 CATCH 块里用 XACT_STATE() 判断状态再决定是否 ROLLBACK。

为什么 TRY CATCH 看似写了却没进 CATCH？

最常见原因是错误根本没进入 TRY 块执行阶段——比如语法错误、对象不存在（SELECT * FROM NonExistTable）、或 GO 分隔导致批处理中断。

• TRY...CATCH 只对当前批处理有效；跨 GO 的 BEGIN TRY 和 BEGIN CATCH 会报语法错误
• DDL 语句（如 CREATE TABLE）出错时可能直接终止批处理，CATCH 来不及触发
• 把 TRY 块写在 IF 或循环体内，而不是批处理最外层，会导致结构不合法
• 严重级别 RAISERROR('msg', 10, 1)）不会跳转到 CATCH，只会输出后继续执行

如何在 CATCH 中拿到真正有用的错误信息？

别只调 ERROR_MESSAGE() ——它常是模糊的通用提示（比如“违反主键约束”），缺乏上下文定位能力。

• 必须在 CATCH 第一行就用变量保存：DECLARE @msg NVARCHAR(4000) = ERROR_MESSAGE(); DECLARE @line INT = ERROR_LINE(); DECLARE @sev INT = ERROR_SEVERITY();
• ERROR_LINE() 返回的是 TRY 块内语句的行号，不是整个存储过程文件的物理行号
• 日志建议拼接：CONCAT('Proc:', OBJECT_NAME(@@PROCID), '; Line:', @line, '; Msg:', @msg)
• 不要在 CATCH 里再执行可能出错的语句（比如查系统表），否则会覆盖原始错误值

事务没回滚？先看 XACT_STATE()，别信 @@TRANCOUNT

@@TRANCOUNT 在某些错误下会失真（比如约束冲突后仍为 1），而 XACT_STATE() 才是事务健康状态的唯一权威依据。

• XACT_STATE() = -1：事务已损坏，不可提交，必须 ROLLBACK TRANSACTION
• XACT_STATE() = 1：事务可提交，但业务逻辑通常要求回滚，所以也该 ROLLBACK
• XACT_STATE() = 0：无活动事务（错误发生在事务外），跳过回滚
• TRY 块开头必须显式 BEGIN TRANSACTION，不能依赖隐式事务或连接级设置

MySQL 或 PostgreSQL 用户注意：别套用 SQL Server 模式

TRY...CATCH 是 SQL Server 特有语法，MySQL 根本不识别，PostgreSQL 用的是 EXCEPTION 块，语义和行为完全不同。

• MySQL 存储过程里的 DECLARE HANDLER 不终止事务，也不自动回滚；ROLLBACK 必须由应用层显式触发
• PostgreSQL 中一旦异常触发，整个事务块即失效，后续 DML 全报 current transaction is aborted；想局部回滚得靠 SAVEPOINT
• 所有数据库都受隐式提交语句影响：比如在事务中执行 CREATE TEMPORARY TABLE，前面修改就永久生效，ROLLBACK 无效

真正容易被忽略的是：错误发生后，连接可能还挂着未结束事务，后续语句看似执行成功，实则数据已处于不一致状态。检查 XACT_STATE() 和及时 ROLLBACK 不是锦上添花，而是防止锁堆积和连接泄漏的底线操作。