SQL Server触发器中不可显式COMMIT，但可ROLLBACK——后者会回滚整个外部事务；BEGIN TRANSACTION仅增加@@TRANCOUNT，RAISERROR不自动回滚需手动ROLLBACK，THROW配合SET XACT_ABORT ON更可靠。
不能在触发器里显式 COMMIT，但可以（且有时必须）ROLLBACK —— 前提是它会回滚整个外部事务，不是只撤回触发器里的操作。
SQL Server 触发器中写 COMMIT TRANSACTION 会报错
SQL Server 直接禁止在触发器内执行 COMMIT TRANSACTION，语句一执行就报错 3609 或直接拒绝解析。因为触发器没有独立事务生命周期，它只是宿主 DML（如 INSERT）事务的一部分。所谓“提交”，只能由最外层调用者决定。
-
BEGIN TRANSACTION在触发器里允许，但只是增加@@TRANCOUNT，不创建新事务 -
COMMIT在触发器中非法，SQL Server 不让你写，写了也过不了语法检查 - 哪怕你用动态 SQL 拼出
EXEC('COMMIT')，也会在编译阶段失败
触发器中 ROLLBACK TRANSACTION 是唯一可控的终止手段
当业务逻辑要求“这次插入/更新必须被否决”，比如校验失败、权限不足、违反业务规则，就得靠 ROLLBACK TRANSACTION 把整个外部事务拉回起点。
- 必须搭配
IF @@TRANCOUNT > 0判断，否则在无事务上下文（如 autocommit 模式）下调用会报错 -
ROLLBACK后建议紧跟RETURN，防止后续语句继续执行造成干扰 - 注意游标：非
STATIC或INSENSITIVE游标会被强制关闭，容易引发后续FETCH报错 - 示例：
IF @amount > 100000 BEGIN RAISERROR('单笔金额超限', 16, 1); IF @@TRANCOUNT > 0 ROLLBACK TRANSACTION; RETURN; END
RAISERROR 不等于回滚，THROW + SET XACT_ABORT ON 才可靠
RAISERROR 只是抛异常，客户端能看见错误，但数据可能已落库——这是最常踩的坑。
- 严重级别
10及以下的RAISERROR不中断执行流，ROLLBACK必须手动写、且必须执行到 -
THROW（SQL Server 2012+）默认中断批处理，但必须提前设SET XACT_ABORT ON，否则约束冲突等底层错误仍可能部分提交 - 别依赖
TRY...CATCH里的RAISERROR就完事：CATCH 块里没ROLLBACK，事务挂起，连接可能被阻塞
跨数据库差异：MySQL 和 PostgreSQL 完全不许碰事务控制
MySQL 触发器里写 COMMIT 或 ROLLBACK 会立刻报错 ERROR 1422 (HY000)；PostgreSQL 的触发器函数若声明为 RETURNS TRIGGER，也不能执行事务命令，只能靠返回 NULL（BEFORE）或 NEW/OLD 控制行为。
- MySQL 唯一能“中断”的方式是
SIGNAL SQLSTATE '45000'，但它是否触发回滚，取决于表引擎（InnoDB 才行）和连接是否处于事务模式（@@autocommit = 0） - PostgreSQL 中，事务边界完全由调用方（比如
BEGIN; INSERT; COMMIT;）控制，触发器只负责改NEW或抛异常 - 所有数据库都一致的原则：触发器不是事务管理者，它是事务里的一个自动执行环节
真正容易被忽略的是：触发器嵌套时，@@TRANCOUNT 会层层累加，但一次 ROLLBACK 就清空全部层级——你不需要也不应该去数嵌套了几层，只要确保它执行在有效事务上下文中即可。
