会，array_agg默认保留null值，如array[1, null, 3]；需用filter (where col is not null)显式过滤，且order by必须写在函数内才能控制数组元素顺序。
ARRAY_AGG 会把 NULL 值也塞进数组里吗？
会。默认情况下 ARRAY_AGG 不过滤 NULL，比如 SELECT ARRAY_AGG(name) FROM users; 若某行 name 为 NULL，结果数组里就真有一个 NULL 元素。
实际中多数场景需要剔除空值，得显式加 FILTER 或用子查询预处理：
ARRAY_AGG(name) FILTER (WHERE name IS NOT NULL)- 或先
WHERE name IS NOT NULL再聚合（更高效，尤其数据量大时）
注意：PostgreSQL 9.4+ 才支持 FILTER 子句；旧版本只能靠 WHERE 或 CASE 配合 ARRAY_CAT 拼接，麻烦且易出错。
怎么控制 ARRAY_AGG 返回数组的顺序？
不加 ORDER BY 就是无序的——不是“随机”，而是按扫描顺序，但这个顺序不可靠，尤其涉及并行查询或后续执行计划变动时。
必须显式用 ORDER BY 子句声明排序逻辑：
ARRAY_AGG(value ORDER BY created_at DESC)-
ARRAY_AGG(name ORDER BY id)—— 多列也支持：ORDER BY status, updated_at DESC
漏掉 ORDER BY 是线上聚合结果偶发错乱的常见原因，尤其在分页或前端渲染依赖顺序时。
聚合字符串时，ARRAY_AGG 和 STRING_AGG 哪个更合适？
看输出目标。如果最终要的是逗号分隔的字符串（如 CSV 导出、日志拼接），直接用 STRING_AGG 更轻量、语义清晰，还自带分隔符和 NULL 处理选项：
-
STRING_AGG(name, ', ' ORDER BY id)—— 自动跳过NULL，不需额外FILTER -
ARRAY_AGG返回的是 PostgreSQL 数组类型（text[]等），适合传给函数进一步处理（如UNNEST、ANY查询、JSON 构造）
误用 ARRAY_AGG 后再用 array_to_string() 转换，多一次函数调用，还可能因类型隐式转换引发错误（比如混合 text 和 integer）。
GROUP BY 字段少写一个，ARRAY_AGG 结果就全乱了
这是最隐蔽也最常踩的坑：ARRAY_AGG 本身不决定分组粒度，完全依赖外层 GROUP BY。少写一个字段，会导致本该分开聚合的记录被强行合并。
例如统计每个部门的员工姓名列表，若漏掉 dept_id：
SELECT ARRAY_AGG(name) FROM employees GROUP BY dept_name;
表面上能跑通，但所有同名部门（哪怕 dept_id 不同）都会被归到同一组——数据逻辑已崩坏，而 PostgreSQL 不报错。
建议：写完 GROUP BY 后，对照业务语义逐个核对字段；复杂查询可先用 SELECT * 查看原始分组键是否唯一，再套聚合。
数组嵌套层级深、分组键多的时候，这个问题特别难回溯。
