是，array_agg 默认保留 null 值，会将其作为数组元素纳入结果（如 [1, null, 3]），易导致 unnest 或下标访问异常；需用 filter (where col is not null) 显式过滤或 coalesce 替换。
ARRAY_AGG 会把 NULL 值也塞进数组里吗？
会，ARRAY_AGG 默认保留 NULL，不像 STRING_AGG 那样默认跳过。如果你的字段有空值，结果数组里就会出现 NULL 元素，后续用 UNNEST 或下标访问时可能触发意外行为。
- 显式过滤：用
WHERE col IS NOT NULL在聚合前剔除 - 用
FILTER (WHERE col IS NOT NULL)（PostgreSQL 9.4+）更精准，不影响其他列的分组逻辑 - 如果必须保留原始行数但想替换
NULL，先用COALESCE(col, 'default')转换再聚合
GROUP BY 字段少写一个，ARRAY_AGG 结果就全乱了
常见错误是只按主键分组，却忘了业务上真正需要“一组什么算一行结果”。比如查每个用户的所有订单 ID：SELECT user_id, ARRAY_AGG(order_id) FROM orders GROUP BY user_id 没问题；但若表里还有 created_at，又误写成 GROUP BY user_id, created_at，那同个用户一天多单就会被拆成多行，数组变短、行数变多。
- 确认语义：你要的是“每个用户一个数组”，还是“每个用户每天一个数组”
- 检查
SELECT中非聚合字段是否全部出现在GROUP BY里——漏一个，PostgreSQL 会直接报错（严格模式），但有些旧版本或配置可能静默出错 - 临时调试时加
COUNT(*)对照：如果COUNT(*)明显大于预期行数，大概率是GROUP BY过细
ORDER BY 在 ARRAY_AGG 里不是可选项，而是关键控制点
ARRAY_AGG 不保证顺序，除非显式声明。即使源表有索引或 ORDER BY 子句在外部，也不影响聚合内部元素排列。没加排序的结果每次执行都可能不同，尤其涉及并行查询时。
- 正确写法：
ARRAY_AGG(order_id ORDER BY created_at DESC) - 可以嵌套表达式：
ARRAY_AGG(UPPER(product_name) ORDER BY price ASC) - 注意性能：
ORDER BY在聚合阶段执行，大数据量时比无序慢；如已知数据天然有序（如按时间分区表），可省略以提速
想转成 JSON 数组？别硬套 ARRAY_AGG + json_build_array
ARRAY_AGG 返回的是 PostgreSQL 的 text[] 或 integer[] 等原生数组类型，不是 JSON。直接把它喂给应用层，某些 ORM 或驱动可能不识别，或序列化成带花括号的字符串而非标准 JSON 数组。
- 要真 JSON：用
JSON_AGG替代，它返回json类型，且自动处理NULL（默认忽略）、转义、嵌套结构 - 混合场景：比如要数组里每个元素是
{id: 1, name: "a"}，用JSON_AGG(JSON_BUILD_OBJECT('id', id, 'name', name)) - 类型不匹配报错？检查字段是否含
bytea、jsonb等不能直接 JSON 化的类型，需先转换（如encode(data, 'base64')）
ORDER BY 和 GROUP BY 的粒度匹配——这两个不盯紧，结果看起来“差不多”，但一上线跑几天数据就对不上。
