BEFORE触发器可修改NEW值并阻止主DML，AFTER不可修改NEW且无法阻止已执行的DML；BEFORE用于默认值、清洗和校验，AFTER用于日志、统计和清理，但失败会导致事务回滚。
BEFORE触发器能改NEW值，AFTER不行
这是最直接、最不可绕过的区别。在 BEFORE INSERT 或 BEFORE UPDATE 中，你可以安全地赋值给 NEW.field，比如强制设置 NEW.created_at := NOW() 或清洗 NEW.email := TRIM(LOWER(NEW.email))。PostgreSQL 会把修改后的 NEW 元组真正写入表中。
AFTER 触发器里对 NEW 赋值完全无效——编译不报错，但运行时 PostgreSQL 忽略它，且不会警告。更严重的是，如果你在 AFTER 里尝试 UPDATE 同一张表（比如想“补更新”某字段），会直接报错：ERROR: cannot update table "xxx" in AFTER trigger。
常见错误现象：
- 把本该放
BEFORE的默认值逻辑挪到AFTER，结果字段仍是 NULL - 在
AFTER UPDATE里写NEW.status := 'done'，以为能覆盖，实际毫无效果 - 误以为
AFTER可以“二次修正”，导致业务数据不一致
AFTER触发器看到的是已提交的最终状态
AFTER 触发器执行时，主 DML 已完成约束检查、外键验证、索引更新，并且所有行级变更已落盘（或至少在当前事务快照中可见）。这意味着你可以放心读取 NEW 和 OLD 值，它们就是用户最终看到的数据。
典型使用场景：
-
AFTER INSERT往日志表插入记录，用NEW.id和current_user -
AFTER UPDATE更新统计表，比如订单状态变'shipped'后，UPDATE order_summary SET shipped_count = shipped_count + 1 WHERE order_id = NEW.order_id -
AFTER DELETE清理关联缓存（如发消息通知 Redis 删除 key）
注意：如果 AFTER 触发器里的 SQL 失败（比如日志表磁盘满、INSERT 违反唯一约束），整个原始事务会回滚——哪怕主语句已经“看起来成功了”。这点常被忽略。
BEFORE触发器可中断操作，AFTER不能阻止主DML
BEFORE 是最后一道防线。你可以在里面做校验，不合法就用 RAISE EXCEPTION 终止整个语句。例如：
IF NEW.amount < 0 THEN RAISE EXCEPTION 'amount must be non-negative'; END IF;
此时 INSERT 或 UPDATE 根本不会执行，数据库状态完全不变。
而 AFTER 触发器无法撤销主操作：即使你在里面 RAISE，主 DML 已生效，事务只能靠回滚来兜底。所以敏感校验（如权限、业务规则）绝不能放在 AFTER。
容易踩的坑：
- 在
AFTER里做“合法性检查”，发现异常再RAISE——为时已晚，数据污染已发生 - 把
BEFORE的校验逻辑拆成两段，一部分放BEFORE（改值），一部分放AFTER（检查），造成逻辑割裂和竞态
行级 vs 语句级 + BEFORE/AFTER 组合影响性能
PostgreSQL 默认是 FOR EACH ROW，即每影响一行就调用一次触发器函数。如果批量插入 10 万行，BEFORE ROW 会执行 10 万次函数调用+元组拷贝；AFTER ROW 同样如此，但还多一次对最终数据的读取开销。
相比之下，FOR EACH STATEMENT 的 BEFORE 或 AFTER 只执行一次，适合全局初始化或收尾（如记录批量导入开始/结束时间），但无法访问单行的 NEW/OLD。
性能建议：
- 高频写入表慎用
FOR EACH ROW的AFTER，尤其涉及跨表UPDATE或远程调用（哪怕只是发消息） - 若只需审计，考虑用
pg_stat_statements或逻辑复制替代行级触发器 -
BEFORE ROW比AFTER ROW略快，因少一次元组读取，但差异通常可忽略
真正难处理的是嵌套：一个 AFTER 插入另一张带 BEFORE 的表，后者又触发更多动作——这种隐式链式调用极易失控，调试困难，且事务膨胀风险高。
