BEFORE INSERT触发器能真正拦截非法数据，因其在数据写入前执行校验，通过SIGNAL抛异常可回滚事务、阻止脏数据入库，是MySQL中唯一可控且符合直觉的拦截时机。
BEFORE INSERT 触发器为什么能真正拦截非法数据
因为它是写入流程中最早可干预的环节：在数据还没进入表、事务尚未提交前就执行校验逻辑。一旦触发器里用 SIGNAL 抛出异常，整个 INSERT 就会回滚，应用层收到明确错误，不会出现“看着成功、实际没写进去”或“写进去了但不合法”的情况。
这和 AFTER INSERT 有本质区别——后者数据已落盘，再抛错只能回滚，但调用方可能已认为操作完成；INSTEAD OF 虽然也能拦截，但 SQL Server 不支持对普通表创建，PostgreSQL 和 MySQL 根本不支持该类型。
关键点：BEFORE INSERT 是唯一既可控又符合直觉的拦截时机。
MySQL / PostgreSQL 中 BEFORE INSERT 触发器的写法差异
MySQL 允许直接在触发器体里引用 NEW.字段名，比如 IF NEW.amount ；而 PostgreSQL 触发器函数内部不能把 <code>NEW 当表用，SELECT id FROM NEW 是语法错误，必须先声明变量：
DECLARE
v_user_blocked BOOLEAN;
BEGIN
SELECT is_blocked INTO v_user_blocked
FROM users WHERE id = NEW.user_id;
IF v_user_blocked THEN
RAISE EXCEPTION '用户已被禁用';
END IF;
RETURN NEW; -- 必须写！漏掉会导致静默丢数据
END;另外注意：
- MySQL 8.0.16+ 才完整支持
CHECK，旧版想做范围校验得靠触发器，但性能和可读性都差一截 - PostgreSQL 触发器函数返回值类型必须是
TRIGGER，结尾必须写RETURN NEW（INSERT/UPDATE）或RETURN OLD（DELETE） - SQL Server 没有
BEFORE概念，只能用INSTEAD OF（仅限视图）或靠存储过程封装 INSERT + 校验
哪些校验适合放 BEFORE INSERT，哪些不该放
适合的场景：
- 单行内字段计算校验，比如
IF NEW.total != (SELECT SUM(price) FROM order_items WHERE order_id = NEW.id) THEN ... - 关联主表状态检查，如查
users.is_active = true，且users.id有主键或唯一索引 - 业务码值合法性，如
NEW.status NOT IN ('draft', 'paid', 'shipped')
不该放的场景：
- 跨表 JOIN 大表查余额、查权限树——容易锁表，高并发下极易死锁
- 调用外部 HTTP 接口或读取文件——触发器不支持，且破坏事务原子性
- 更新其他业务表（比如插入订单时扣库存）——属于业务动作，不是校验，应移出触发器
- 用
SELECT *或无索引字段过滤，比如WHERE name LIKE '%张%'——全表扫描拖慢所有 INSERT
常见报错与静默失败陷阱
最容易被忽略的是返回值缺失：PostgreSQL 触发器函数漏写 RETURN NEW，MySQL 触发器里忘了 SET NEW.xxx = ...（如果要改值），结果数据看似插入成功，实则字段为空或默认值被硬塞，问题延迟暴露。
另一个高频坑是 NULL 处理：比如写 CHECK (age > 18)，当 age IS NULL 时约束不生效；正确写法是 age IS NOT NULL AND age > 18，或者在触发器里显式判断 IF NEW.age IS NULL THEN SIGNAL ...。
还有字符集陷阱：校验 WHERE code = 'ABC' 在 utf8mb4_0900_as_cs 排序规则下区分大小写，测试环境若用 utf8mb4_general_ci 就可能漏掉问题。
