为什么PostgreSQL触发器可以精确控制触发时机

before触发器可修改new值并阻止主dml，after不可修改new且无法阻止已执行的dml；before用于默认值、清洗和校验，after用于日志、统计和清理，但失败会导致事务回滚。

为什么postgresql触发器可以精确控制触发时机_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 
<p>此时 <code>INSERT</code> 或 <code>UPDATE</code> 根本不会执行，数据库状态完全不变。</p>
<p>而 <code>AFTER</code> 触发器无法撤销主操作：即使你在里面 <code>RAISE</code>，主 DML 已生效，事务只能靠回滚来兜底。所以敏感校验（如权限、业务规则）绝不能放在 <code>AFTER</code>。</p>
<p>容易踩的坑：</p>