hstore不能自动捕获字段变更，因null比较失效、类型隐式转换干扰，须用is distinct from逐字段判断；其仅适合封装结果，差集操作需用-并coalesce处理null。
不能直接用 hstore 自动捕获字段变更 —— 它只做键值映射，不解决 NULL 比较、语义差异或性能陷阱。
为什么 hstore 在 UPDATE 触发器里容易漏判变更
hstore(NEW.*) 和 hstore(OLD.*) 看似能一键转成键值对，但实际比对时会踩两个坑：
- NULL 值比较失效：
'a'::text = NULL返回NULL（不是false），导致hstore(NEW.*) = hstore(OLD.*)判定失败，误认为“有变化” - 类型隐式转换干扰：比如
numeric字段存1.0和1，hstore序列化后字符串不同，但业务上是等价的
正确做法是仍需逐字段用 IS DISTINCT FROM 判断，hstore 只适合最后封装结果，不能替代逻辑判断。
hstore 如何安全封装变更字段（附最小可行代码）
在触发器函数中完成字段比对后，用 hstore 构建变更快照，比拼接 JSON 字符串更轻量、支持索引查询：
SELECT hstore(ARRAY[ 'name', COALESCE(NEW.name::text, ''), 'email', COALESCE(NEW.email::text, '') ]) - hstore(ARRAY[ 'name', COALESCE(OLD.name::text, ''), 'email', COALESCE(OLD.email::text, '') ]);
注意三点：
- 必须用
-（hstore 差集操作符），不是!=；它能自动剔除相同键值对 -
COALESCE(..., '')统一 NULL 表示，避免差集计算中断 - 别对大文本字段（如
TEXT、JSONB）直接转hstore，可能超长或乱码，应先截断或跳过
audit_table 设计中 hstore 字段要不要加索引
如果审计表里用 changed_fields hstore 存变更详情，不要建普通 B-Tree 索引，而应建 GIN 索引：
CREATE INDEX idx_audit_changed_gin ON audit.record_version USING GIN (changed_fields);
原因很实在：
- B-Tree 对
hstore只能做整体相等查询，查“哪个字段被改了”毫无用处 - GIN 支持
changed_fields ? 'email'（查是否含 email 键）、changed_fields @> 'email=>new@b.c'（查 email 是否变为此值） - 但 GIN 索引体积比 B-Tree 大 3–5 倍，写入略慢，高并发 UPDATE 场景需压测确认吞吐是否达标
hstore 替代方案：jsonb 更通用，但别盲目切换
很多新项目直接用 jsonb 存变更，确实支持嵌套、类型保留、原生函数多。但它不是银弹：
-
jsonb的old_value/new_value结构需要手写jsonb_build_object，代码比hstore多 2–3 行 -
hstore的akeys()、skeys()提取字段名更快，适合做“统计哪些字段最常被改”这类分析 - 若已用
hstore上线且无性能瓶颈，没必要为“看起来更现代”换成jsonb—— 审计系统稳定压倒一切
真正关键的不是选 hstore 还是 jsonb，而是字段比对逻辑是否严格、上下文参数（如 current_setting('app.user_id', true)）是否可靠传入、以及审计写入是否异步隔离主事务。
