mysql触发器中禁止显式commit或rollback，预扣除操作必须由外层事务统一控制；正确做法是在before update触发器中仅做余额校验并抛出错误中断，而非执行真实扣减，以保障事务原子性与一致性。
触发器里不能直接 COMMIT 或 ROLLBACK
金融转账的预扣除必须保证原子性，但 MySQL / PostgreSQL 的触发器内禁止显式提交事务。一旦在 BEFORE UPDATE 触发器里写 UPDATE accounts SET balance = balance - 100 WHERE id = 1，后续业务逻辑出错时，这个扣减不会自动回滚——除非整个外部事务失败，否则它就“提前生效”了。所以预扣除不能靠触发器独立完成，得靠外层事务控制生命周期。
用 BEFORE UPDATE 触发器做余额校验而非真实扣减
真正安全的做法是：在转账语句执行前，用触发器检查付款方余额是否足够，并抛出错误中断操作。这样既不破坏事务一致性，又防止超支。示例（MySQL）：
CREATE TRIGGER check_balance_before_transfer
BEFORE UPDATE ON accounts
FOR EACH ROW
BEGIN
IF NEW.id = OLD.id AND NEW.balance != OLD.balance THEN
IF NEW.balance <p>注意这里只校验变更后的 <code>NEW.balance</code> 是否为负，不主动修改；真正的扣减由应用层或存储过程在事务中完成。</p><h3>预扣除必须和转账操作在同一事务中完成</h3><p>所谓“预扣除”，本质是把“冻结额度”作为转账事务的第一步。常见错误是分两步：先 UPDATE 扣减，再 INSERT 转账记录——这中间若崩溃，钱就丢了。正确做法是：</p>
- START TRANSACTION
- UPDATE accounts SET balance = balance -
amountWHERE id =from_id - UPDATE accounts SET balance = balance +
amountWHERE id =to_id - INSERT INTO transfers (from_id, to_id, amount) VALUES (...)
- COMMIT 或 ROLLBACK
触发器只负责在第一步 UPDATE 时拦截非法值，不替代事务逻辑。
PostgreSQL 中 trigger 函数返回 NULL 会取消整行更新
PG 的 BEFORE 触发器函数如果返回 NULL，当前行更新会被跳过——这对预扣除场景很危险。比如你写了校验逻辑后忘了写 RETURN NEW，整个转账 UPDATE 就静默失效了。务必确保函数末尾有：
RETURN NEW; -- 或 RETURN OLD（仅限 AFTER）
另外，PG 不支持在触发器里调用 pg_advisory_lock() 做并发控制，高并发转账仍需靠应用层加锁或使用 SELECT ... FOR UPDATE 显式锁定账户行。
预扣除不是让触发器去“干活”，而是让它当守门人。真正的资金动作必须严格绑定在外部事务里，否则任何看似巧妙的触发器设计都会在并发或异常下暴露一致性漏洞。
