BEFORE UPDATE 是唯一能真正拦截非法状态的时机，必须在此阶段触发校验并中断执行，AFTER 触发器无法阻止数据落盘；状态流转需显式枚举合法路径，终态字段冻结须按字段精确判断，权限校验应依赖应用层传入上下文而非数据库会话。
BEFORE UPDATE 是唯一能真正拦截非法状态的时机
触发器必须写在 BEFORE UPDATE 阶段，否则无法阻止非法状态写入。AFTER 触发器里再 SIGNAL 或 RAISERROR，数据已经落盘，回滚对应用不可见，前端可能显示“更新成功”但实际被撤回——这是最典型的误用。
MySQL、PostgreSQL、Oracle 都只允许在 BEFORE 中中断执行；SQL Server 虽无 BEFORE，但必须在 AFTER 里立刻 RAISERROR + ROLLBACK TRANSACTION，且错误级别得是 16，低了不中断，高了会断连。
- 漏写
SIGNAL SQLSTATE '45000'（MySQL）或RAISERROR(..., 16, 1)（SQL Server），等于没拦 - 用
SELECT 1/0替代SIGNAL（旧版 MySQL）：错误信息不可控，日志难排查 - 在触发器里只做
IF ... THEN SET @msg = 'xxx'却不抛错：完全无效
状态跳转必须显式枚举合法路径，不能靠否定排除
业务状态流转不是“除了这几个都不能”，而是“只有这几个才允许”。比如 draft → reviewing、reviewing → paid、paid → refunded 是合法路径，那就要一条条写死，而不是写“IF NEW.status NOT IN ('reviewing', 'paid', 'refunded') THEN ...”——漏掉一个合法值，就等于放行非法变更。
示例（MySQL）：
IF OLD.status = 'paid' AND NEW.status NOT IN ('refunded', 'reversed') THEN
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'paid 状态只允许转为 refunded 或 reversed';
END IF;
- 状态字段必须是
ENUM或带CHECK约束的VARCHAR，否则NEW.status可能存入拼写错误如'padi'，触发器判不出 - 别混用
WEEKDAY()和DAYOFWEEK()：前者周一=0，后者周日=1，逻辑会翻车 - 禁止在条件里查其他表（如
SELECT role FROM users WHERE id = NEW.user_id），高并发下极易锁表或报 ERROR 1442
终态字段冻结需复合判断，不能只看状态
状态变成 paid 或 closed 后，并非所有字段都该锁死。比如 updated_at、memo 通常允许更新，但 amount、currency、invoice_no 必须冻结。触发器得同时校验状态 + 字段变更，而不是一棍子打死整行。
正确写法是：
IF OLD.status IN ('paid', 'closed')
AND (NEW.amount != OLD.amount
OR NEW.currency != OLD.currency
OR NEW.invoice_no != OLD.invoice_no) THEN
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '终态记录禁止修改金额、币种与单号';
END IF;
- 不要写成
IF OLD.status = 'paid' THEN ...就拦全部更新——会误杀updated_at -
NOT (NEW.memo = OLD.memo)不够严谨，应直接列出允许更新的字段，其余默认冻结 - MySQL 触发器内禁止
START TRANSACTION或ROLLBACK，想“部分回滚”不可能，只能靠前置校验堵死
应用层必须传操作人上下文，触发器看不到 session 变量
触发器无法获取当前登录用户的角色、部门、权限组。像“只有财务主管能将状态设为 paid”这种规则，不能靠 CURRENT_USER() 或查 pg_roles 实现——PostgreSQL 查不到有效角色，MySQL 根本不许查系统表，SQL Server 的 IS_MEMBER() 在触发器里常返回 NULL。
可靠做法是：应用在事务开始前，显式设置会话变量，比如 MySQL 的 SET @current_app_user = 'fin_admin_123';，然后触发器里用 COALESCE(@current_app_user, CURRENT_USER()) fallback。
- 别指望触发器自动识别“谁点了提交”，它只看到 SQL 语句里的值
- Row Level Security（PostgreSQL RLS）或存储过程（MySQL）比触发器更适合做动态权限判定
- 如果应用没传，触发器只能按字段推断（如
IF NEW.approver_id = OLD.creator_id），但这类逻辑应尽量下沉到应用层，避免数据库承担业务语义
复杂点在于：状态机规则不是静态的，它随业务演进频繁调整；而触发器一旦上线，每次改都要 DBA 审批、停写窗口、验证回滚方案。真正稳定的方案，是把核心状态校验留在应用层，触发器只做兜底——比如防脚本误操作、拦明显越权字段修改。
