存储过程中直接commit/rollback会报错266，因为sql server要求过程入口与出口的@@trancount值必须一致；若调用方已开启事务（@@trancount=1），过程内commit使其变为0、rollback直接归零，导致退出时计数不匹配。
COMMIT TRANSACTION 或 ROLLBACK TRANSACTION，否则大概率触发错误 266（事务计数不匹配）。
为什么存储过程中直接 COMMIT/ROLLBACK 会报错 266？
SQL Server 的事务计数（@@TRANCOUNT）必须在存储过程入口和出口保持一致。如果调用方已开启事务（@@TRANCOUNT = 1），而你在过程里执行了 COMMIT TRANSACTION，它会让 @@TRANCOUNT 变成 0；执行 ROLLBACK TRANSACTION 则直接归零——两者都会导致退出时计数不匹配，引发错误 266。
- 错误示例：
ROLLBACK TRANSACTION后不加BEGIN TRANSACTION补位，就会出错 - 正确做法：只在存储过程内部做“局部控制”，把事务边界留给调用方决定
- 例外情况：只有当存储过程是顶层调用（即外部没有 BEGIN）、且你明确要终结整个事务时，才可 COMMIT/ROLLBACK ——但这种设计通常不合理
如何让存储过程安全参与外部事务？
默认情况下，存储过程只是外部事务的一部分，它的所有 DML 操作自动被包含进去。你只需专注逻辑，不用管 COMMIT/ROLLBACK ——由调用者统一处理。
- 确保不写
COMMIT/ROLLBACK，也不写BEGIN TRANSACTION（除非你要嵌套） - 若需部分回滚（比如某一步失败但想保留前面的修改），改用
SAVE TRANSACTION @savepoint_name+ROLLBACK TRANSACTION @savepoint_name - 用
SET XACT_ABORT ON开启后，运行时错误会自动触发整个事务回滚（比手动检查@@ERROR更可靠）
触发器里回滚有什么特殊限制？
触发器总在隐式事务中运行，且退出时 @@TRANCOUNT 必须为 0，否则报错 3609 并终止批处理。
-
ROLLBACK TRANSACTION在触发器里允许，但它会回滚整个外部事务（不只是触发器内操作） - 触发器里的
COMMIT是非法的，SQL Server 直接拒绝执行 - 如果触发器内需要 BEGIN，那必须配对 COMMIT 或 ROLLBACK，否则
@@TRANCOUNT不平衡 - 游标行为受 ROLLBACK 影响：非 STATIC/INSENSITIVE 游标会被关闭，这点容易被忽略
真正可控的事务管理该放在哪一层？
事务控制权应该交给最外层的应用代码或调用批处理，而不是分散在存储过程或触发器里。
- 应用层（如 C#）用
SqlTransaction调用BeginTransaction()→ 执行多个存储过程 → 最终Commit()或Rollback() - T-SQL 批处理中显式写
BEGIN TRANSACTION→ 多个EXEC proc_x→COMMIT或ROLLBACK - 存储过程只负责「做事情」，不负责「拍板是否生效」——这是职责分离的关键
最容易被忽略的点是：哪怕存储过程只读、没写任何数据，只要它内部执行了 BEGIN TRANSACTION，就必须保证出口时 @@TRANCOUNT 和入口一致。这点在嵌套调用和异常路径下极难兜住，所以尽量避免在过程里碰事务语句。
