SQL Server中TRY CATCH不会自动回滚事务，必须在CATCH中根据XACT_STATE()手动ROLLBACK；需配合SET XACT_ABORT ON确保运行时错误触发自动回滚，且错误处理应使用THROW而非RAISERROR。
SQL Server里TRY CATCH不能自动回滚事务
直接写 TRY CATCH 包住 INSERT 语句，失败了事务照样没回滚——这是最常踩的坑。SQL Server 的 TRY CATCH 只捕获错误，不干预事务状态；如果 INSERT 在显式事务中出错，CATCH 块里必须手动 ROLLBACK，否则连接可能还挂着未提交的事务。
典型错误现象：Msg 2627, Level 14, State 1, Line X — Violation of PRIMARY KEY constraint 报完错，查表发现部分数据已插入，事务卡在 OPEN 状态。
- 必须用
BEGIN TRY ... END TRY BEGIN CATCH ... END CATCH包裹整个事务逻辑 -
CATCH块里第一件事是检查XACT_STATE()：值为-1表示事务不可提交（必须ROLLBACK），0表示已回滚，1表示可提交（但批量插入失败时几乎不会是 1） - 别依赖
@@ERROR—— 它只保留上一条语句的错误号，进CATCH后就失效了；改用ERROR_NUMBER()、ERROR_MESSAGE()等函数
批量插入前要设好XACT_ABORT ON
默认情况下，某些严重错误（比如违反约束）会让 SQL Server 自动回滚当前批处理，但有些错误（如转换失败）却不会，导致事务处于“不可提交但未回滚”状态。开启 SET XACT_ABORT ON 后，只要发生运行时错误，整个事务立刻终止并回滚，和 TRY CATCH 配合更可靠。
- 放在
BEGIN TRY外面，或至少在BEGIN TRANSACTION之前执行 - 不加它，
INSERT INTO ... SELECT中某行转换失败（如varchar转int），其余行可能已插入，CATCH还捕不到错误（取决于错误级别） - 注意：它对编译期错误（如语法错、对象不存在）无效，这类错误根本进不了
TRY块
INSERT...SELECT 和 INSERT...VALUES 的回滚行为一致吗？
一致。事务粒度不看 INSERT 写法，而看是否在同一个 BEGIN TRANSACTION 内。但实际使用中，INSERT...SELECT 更容易触发隐式事务或锁等待，间接影响 CATCH 捕获时机。
- 用
INSERT...SELECT批量插 10 万行时，若第 5 万行违反唯一约束，前 49999 行已写入，必须靠ROLLBACK清掉 -
INSERT...VALUES多值插入（SQL Server 2008+）算作单条语句，要么全成，要么全败——但依然要包在事务里，因为失败后连接状态不确定 - 避免在循环里逐条
INSERT+TRY CATCH：性能差，且每次都要开新事务，无法保证原子性
一个最小可行的带回滚的批量插入模板
下面这段可以直接复制修改使用，重点看 XACT_ABORT、XACT_STATE() 判断、以及 ROLLBACK 的位置：
SET XACT_ABORT ON;
BEGIN TRY
BEGIN TRANSACTION;
<pre class='brush:php;toolbar:false;'>INSERT INTO dbo.Users (Id, Name, Email)
SELECT Id, Name, Email
FROM #StagingUsers
WHERE Email IS NOT NULL;
COMMIT TRANSACTION;END TRY BEGIN CATCH IF XACT_STATE() <> 0 ROLLBACK TRANSACTION;
-- 记录错误（可选）
DECLARE @msg NVARCHAR(2048) = FORMATMESSAGE(
'Batch insert failed: Error %d, Message: %s',
ERROR_NUMBER(),
ERROR_MESSAGE()
);
THROW 50000, @msg, 1;END CATCH
注意 THROW 是 SQL Server 2012+ 推荐方式，比 RAISERROR 更准确传递原始错误上下文；如果用旧版本，得手动拼 RAISERROR 并传入 ERROR_LINE() 等。
真正麻烦的不是写这几行，而是确保所有参与批量插入的临时表（如 #StagingUsers）、约束、触发器都提前验证过——这些地方出问题，CATCH 能捕到，但回滚后你得知道到底哪一行、哪个约束坏了。
