行级触发器中仅 before 触发器可通过修改 new 并 return new 实现字段自动计算；after 触发器中 new 只读，赋值无效且高版本会报错。
行级触发器不能直接“计算字段并自动存入”，它只能在 INSERT/UPDATE 时通过修改 NEW 记录来影响即将写入的值——这要求你用 BEFORE INSERT OR UPDATE，且必须 RETURN NEW。
为什么 AFTER 触发器无法用于字段计算
AFTER 触发器里的 NEW 和 OLD 是只读的，任何对 NEW.field := ... 的赋值都会被忽略。你看到字段没变，不是逻辑写错了，是根本没执行入口。
- 常见错误现象：
ERROR: cannot assign to NEW.field in AFTER trigger（高版本 PostgreSQL 会直接报错） - UPDATE 场景下若误用 AFTER，还可能因事务已提交而错过数据一致性校验时机
- 唯一能“改数据”的窗口，就是 BEFORE 行级触发器中修改
NEW并显式RETURN NEW
BEFORE 触发器中安全计算字段的实操要点
字段计算逻辑必须明确、无副作用，且所有依赖字段都得在 NEW 中存在（即 INSERT/UPDATE 语句里显式提供了值，或有默认值）。
- 计算字段如
full_name：写成NEW.full_name := TRIM(CONCAT(NEW.first_name, ' ', NEW.last_name))，再RETURN NEW - 避免调用需事务外资源的函数（如外部 HTTP 请求、文件读取），否则会阻塞整个 DML
- 若计算依赖其他表（如根据
category_id查名称生成标签），必须用SELECT ... INTO同步查，不能用子查询直接赋值到NEW字段（语法不支持） - 注意 NULL 处理：字符串拼接中任一字段为
NULL会导致整个结果为NULL，应提前用COALESCE或NULLIF
动态字段名计算要绕开 EXECUTE
别试图在触发器里用 EXECUTE 动态设置某个字段——NEW 是 RECORD 类型，不支持 EXECUTE 'NEW.' || field_name := ... 这种写法。它没有反射式赋值能力。
- 正确做法：把需要计算的字段列表硬编码进触发器函数，例如只处理
price和tax_rate推出total_price - 如果真要“配置化”字段逻辑（比如从配置表读规则），只能提前生成多个专用触发器函数，或改用应用层计算 + 数据库约束校验
- 动态 SQL 只适用于写日志、发通知等旁路操作；改
NEW必须静态字段引用
容易被忽略的并发与默认值陷阱
当字段有默认值（如 created_at TIMESTAMP DEFAULT NOW()），且你又在 BEFORE 触发器里给它赋值，PostgreSQL 会以触发器中的赋值为准——但前提是该字段未在 INSERT/UPDATE 语句中显式出现。
- INSERT INTO users (name) VALUES ('alice') → 触发器可安全设
NEW.created_at - INSERT INTO users (name, created_at) VALUES ('alice', '2020-01-01') → 触发器里再设
NEW.created_at会被覆盖，因为语句已提供值 - UPDATE users SET name = 'bob' WHERE id = 1 → 若触发器想重算
updated_at，必须检查NEW.updated_at IS NULL或用WHEN子句限定仅当字段未被更新时才介入
最危险的是多字段联动计算（比如 start_time 和 duration 推出 end_time），一旦两个字段在同一条 UPDATE 中都被指定，顺序不可控，结果可能错乱。这种场景建议放弃触发器，改用应用层统一构造。
