@@TRANCOUNT返回当前连接未提交/未回滚的BEGIN TRANSACTION嵌套层数，非布尔值；BEGIN使计数加1，COMMIT减1，ROLLBACK（无保存点）清零；SAVE TRANSACTION及对应ROLLBACK不改变该值；需配合XACT_STATE()判断事务可提交性。
@@TRANCOUNT 返回的是事务嵌套层数，不是“是否在事务中”的布尔值
很多人误以为 @@TRANCOUNT = 1 表示“有事务”，@@TRANCOUNT = 0 表示“没事务”，其实它精确反映的是当前连接上未提交/未回滚的 BEGIN TRANSACTION 嵌套次数。哪怕只执行了一次 BEGIN TRAN，@@TRANCOUNT 就是 1；再嵌套一次就是 2；COMMIT 一次就减 1；而 ROLLBACK TRANSACTION（无保存点）会直接清零。
这意味着：你在存储过程中看到 @@TRANCOUNT = 2，说明调用链里外层已开启事务（比如由上层 SP 或应用程序显式 BEGIN），你当前 SP 又自己 BEGIN 了一次——但这种“双重 BEGIN”在 SQL Server 中合法，只是语义上属于嵌套事务（实际仍受最外层控制）。
在存储过程中安全判断“是否需自行 COMMIT/ROLLBACK”
不能仅靠 @@TRANCOUNT = 0 就决定开启事务，也不能在 @@TRANCOUNT > 0 时盲目 COMMIT——因为 COMMIT 会把外层事务也提前结束，破坏调用方的事务边界。
- 若你希望该存储过程“自治”（即无论被谁调用都独立完成事务），应在开头检查：
IF @@TRANCOUNT = 0 BEGIN BEGIN TRANSACTION END，并在结尾配对IF @@TRANCOUNT > 0 COMMIT TRANSACTION - 若你希望“融入调用方事务”（更常见），则**绝不主动 COMMIT 或 ROLLBACK**，只做业务逻辑；错误时抛出异常，让外层决定回滚
- 特别注意：
SAVE TRANSACTION savepoint_name不改变@@TRANCOUNT，但ROLLBACK TRANSACTION savepoint_name也不会减少它——这是唯一能局部回滚又不破坏事务计数的操作
@@TRANCOUNT 在 TRY/CATCH 中的行为容易被忽略
SQL Server 的 TRY/CATCH 不会自动重置 @@TRANCOUNT，也不会隐式提交或回滚。如果在 TRY 块里执行了 BEGIN TRAN，然后发生错误跳入 CATCH，此时 @@TRANCOUNT 仍为 1 —— 若 CATCH 中未显式 ROLLBACK，后续语句可能意外运行在未关闭的事务上下文中。
典型防御写法：
BEGIN TRY BEGIN TRANSACTION; -- ... 业务操作 COMMIT TRANSACTION; END TRY BEGIN CATCH IF @@TRANCOUNT > 0 ROLLBACK TRANSACTION; -- 再抛出错误 THROW; END CATCH
这里 IF @@TRANCOUNT > 0 判断必不可少：避免在外部已回滚、而 CATCH 又重复 ROLLBACK 导致 “The ROLLBACK TRANSACTION request has no corresponding BEGIN TRANSACTION” 错误。
嵌套事务下 @@TRANCOUNT 和 XACT_STATE() 的分工
@@TRANCOUNT 告诉你“开了几层”，但不告诉你事务是否还能用；XACT_STATE() 才回答“当前事务是否可提交”。例如：
-
@@TRANCOUNT = 1且XACT_STATE() = -1→ 事务已因错误进入不可提交状态，只能ROLLBACK -
@@TRANCOUNT = 1且XACT_STATE() = 1→ 事务健康，可COMMIT或ROLLBACK -
@@TRANCOUNT = 0→ 必然XACT_STATE() = 0，无活动事务
所以真正健壮的事务处理逻辑，往往要同时检查二者：IF @@TRANCOUNT > 0 AND XACT_STATE() = 1 COMMIT TRANSACTION，否则优先 ROLLBACK。
