触发器中字段变更检测必须用 is distinct from 而非 = 或 !=，因 null 参与时后者恒返回 null（被当作 false）；函数操作需用 coalesce 显式兜底防报错；null 检测一律用 is null/is not null；多层嵌套或 jsonb 场景需分层处理。
触发器里用 = 或 != 判断字段变更会失效
只要字段可能为 NULL，= 和 != 在触发器中就不可信。比如 OLD.status != NEW.status，当任一端为 NULL 时结果恒为 NULL，而触发器的 WHEN 子句只认 TRUE，NULL 被当作 FALSE 处理，逻辑直接跳过。
常见现象：你写了更新检测，但 NULL 参与后该触发的没触发，日志里也看不到痕迹，还以为条件没满足。
- 必须改用
OLD.col IS DISTINCT FROM NEW.col—— 这是 PostgreSQL 原生支持的唯一能正确处理 NULL 的标量比较方式 - 不能写成
NEW.col IS DISTINCT FROM OLD.col，虽然语义等价，但可读性差，容易在多人协作中引发歧义 - 多个字段需用
AND连接，例如OLD.a IS DISTINCT FROM NEW.a AND OLD.b IS DISTINCT FROM NEW.b -
IS NOT DISTINCT FROM等价于=但兼容 NULL，不过它更常用于反向逻辑（如“未变化”），日常变更检测优先用IS DISTINCT FROM
BEFORE 触发器中对 NULL 字段做函数操作会报错
像 UPPER(NEW.name)、NEW.price * NEW.quantity 这类操作，只要任意参数为 NULL，整个表达式结果就是 NULL；但某些函数（如 UPPER）在传入 NULL 时会直接报错，比如 ERROR: function upper(unknown) does not exist。
这不是数据库 bug，而是类型推导失败——NULL 没有明确类型，函数无法匹配签名。
- 必须用
COALESCE显式兜底，例如UPPER(COALESCE(NEW.email, ''))或COALESCE(NEW.price, 0) * COALESCE(NEW.quantity, 1) -
COALESCE的所有参数类型要一致，COALESCE(NEW.name, 123)在多数版本中会创建失败 - 在
BEFORE INSERT中，OLD不可用，所以只能依赖NEW.field和默认值，别误写OLD.field - 别写完
COALESCE(NEW.email, '')后又去调LENGTH(NEW.email)—— 这里还是原始 NULL，得写成LENGTH(COALESCE(NEW.email, ''))
WHERE 条件或 IF 判断里直接写 = NULL 永远不成立
IF NEW.status = NULL 或 WHERE old_value = NULL 这类写法永远返回 UNKNOWN，实际效果等同于 FALSE，整段分支被跳过。这是三值逻辑的固有行为，不是 bug。
典型症状：触发器看似运行成功，但本该执行的插入、拒绝或日志记录完全没发生，排查时容易卡在“条件写对了为什么没走”。
- 一律改用
NEW.status IS NULL或NEW.status IS NOT NULL - 如果想把 NULL 当作某个默认值参与后续逻辑（比如设为 “待审核”），用
COALESCE(NEW.status, 'pending')，而不是先判断再赋值 - 别在子查询或关联条件里混用
= NULL，尤其在IN或标量子查询中，NULL 会导致整行失效或静默丢失
多层嵌套或复合类型场景下 NULL 处理容易漏掉
IS DISTINCT FROM 只支持标量类型（int、text、date 等），对 jsonb、数组、范围类型等默认不生效；COALESCE 在面对 jsonb 字段时虽可用，但若内部键值为 NULL，它不会递归处理。
比如 NEW.payload::jsonb ->> 'user_id' 返回 NULL，COALESCE 能兜住这一层，但如果你接着做 (NEW.payload::jsonb -> 'items') @> '[{"id":1}]'，而 items 是 NULL，整个表达式仍为 NULL，且不会报错。
- 对 JSONB 字段，优先用
jsonb_path_exists()或jsonb_typeof()显式检查结构是否存在 - 数组比较不要用
=，改用array_length()+ 元素级比对，或转成字符串再比较（谨慎用于大数据量） - 涉及
jsonb的业务逻辑，建议在触发器开头就用COALESCE(NEW.payload, '{}'::jsonb)统一兜底，避免后续层层判空
NULL 的处理不是加几个 IS NULL 就完事，关键在于区分“检测存在性”和“参与运算”两种场景——前者用 IS [NOT] NULL，后者用 COALESCE 或 IS DISTINCT FROM。最容易被忽略的是：同一个字段在触发器不同位置可能承担不同角色，漏掉其中一处，整条逻辑链就断了。
