string_agg()是postgresql专用于字符串聚合的原生函数，需严格按string_agg(expression, delimiter order by ...)语法使用，注意类型转换、null处理、group by完整性及排序位置。
直接用 STRING_AGG()，别绕路拼数组或写应用层循环——它就是专干这个的，原生、快、行为可控。
STRING_AGG 参数顺序不能颠倒
必须是 STRING_AGG(expression, delimiter)，第一个是待拼接的字段或表达式，第二个是分隔符。颠倒会直接报错：
-
STRING_AGG(', ', name)→ 报错function string_agg(unknown, text) does not exist，因为 PostgreSQL 无法推导类型 - 数字或 UUID 字段要显式转文本：
STRING_AGG(order_id::text, ', ')或STRING_AGG(CAST(user_id AS TEXT), ';') - 分隔符可以是任意字符串，包括空字符串
''（无缝拼接），但绝不能为NULL，否则整组结果变NULL
不加 ORDER BY 时拼接顺序是未定义的
没写排序子句，结果顺序由执行计划决定，同一查询多次运行可能返回不同字符串。外层 ORDER BY 完全无效——它只影响最终行序，不控制拼接内部顺序。
- 正确写法：
STRING_AGG(name, ', ' ORDER BY created_at DESC)，ORDER BY必须写在括号内、分隔符之后 - 支持多字段排序：
STRING_AGG(tag, ' | ' ORDER BY status NULLS LAST, updated_at DESC) - 排序字段必须来自
GROUP BY列或聚合表达式，不能引用未分组的列（如email未出现在GROUP BY中就不可用） - 空值默认排最前，要统一置后得加
NULLS LAST，哪怕STRING_AGG本身已跳过NULL值
GROUP BY 漏写或字段不匹配会导致数据错乱
这是线上最常引发错误的点：想按用户合并标签，却忘了 GROUP BY user_id，或者用了非唯一字段（如 username）当分组依据。
-
SELECT user_id, STRING_AGG(tag, ', ') FROM user_tags;→ 报错：column "user_tags.user_id" must appear in the GROUP BY clause - 所有非聚合列（如
user_id、category）必须完整出现在GROUP BY中，且不能用AS别名（如GROUP BY uid无效，得写GROUP BY t.user_id） - 若字段是数组类型（如
tags text[]），不能直接传给STRING_AGG()，需先unnest()展开：SELECT STRING_AGG(elem, ', ') FROM (SELECT unnest(tags) AS elem FROM posts WHERE id = 123) t;
空字符串和去重需要主动处理
STRING_AGG 默认跳过 NULL，但不会过滤空字符串 ''，会导致结果出现多余分隔符（如 北京、、上海）；去重仅支持单字段语法。
- 把空字符串转
NULL再拼接：STRING_AGG(CASE WHEN city = '' THEN NULL ELSE city END, '、') - 单字段去重用
DISTINCT：STRING_AGG(DISTINCT tag, ', ') - 多字段组合去重需预处理，比如用
DISTINCT ON或 CTE 先 dedupe，再聚合 - 拼接结果过长？PostgreSQL 无硬限制，但客户端或应用层可能截断，必要时套
SUBSTRING(STRING_AGG(...), 1, 1000)
最易被忽略的是：排序子句必须严格落在函数括号内，且 GROUP BY 字段必须与 SELECT 中非聚合列完全一致——差一个表别名或漏一个字段，结果就不可信。
