STRING_AGG的ORDER BY必须写在函数括号内、分隔符之后，如STRING_AGG(name, ', ' ORDER BY created_at DESC)；它仅支持GROUP BY中出现的列或可计算表达式，NULL值被跳过但参与排序，默认NULLS FIRST，需显式用NULLS LAST避免干扰；非TEXT类型须显式转换，分隔符为NULL会导致整个结果为NULL。
STRING_AGG的ORDER BY必须写在括号内、分隔符之后
很多人把ORDER BY写在外部查询里，比如：SELECT STRING_AGG(name, ', ') FROM users ORDER BY created_at DESC——这完全没用，拼出来的字符串顺序还是随机的。真正起作用的排序必须嵌在STRING_AGG()函数内部，且语法位置固定：分隔符后面、括号闭合前。
正确写法是：STRING_AGG(name, ', ' ORDER BY created_at DESC)。注意三个关键点：
-
ORDER BY不是独立子句，不能脱离STRING_AGG()括号存在 - 它只能引用当前
GROUP BY中出现的列，或该分组内可计算的表达式（如LENGTH(name)） - 不支持引用未分组的字段，比如
email若没出现在GROUP BY里，ORDER BY email会直接报错
NULL值既被跳过，又参与排序计算
STRING_AGG()默认跳过NULL值（不拼进结果），但ORDER BY子句仍会对这些NULL做排序定位——只是最后不把它们塞进去。这会导致一个隐蔽问题：如果你写STRING_AGG(name, ', ' ORDER BY name)，而name有NULL，它们会被排在最前面（NULLS FIRST默认行为），虽不显示，但可能挤占非NULL值的相对位置逻辑。
安全做法是显式控制NULL位置：
- 让
NULL沉底：STRING_AGG(name, ', ' ORDER BY name NULLS LAST) - 彻底排除干扰：用
COALESCE(name, '')或CASE WHEN name IS NULL THEN '' ELSE name END提前转换 - 若业务上
NULL和空字符串都应忽略，可合并处理：STRING_AGG(NULLIF(TRIM(name), ''), ', ' ORDER BY name NULLS LAST)
非TEXT类型字段必须显式转换
STRING_AGG()只接受文本类输入，对integer、uuid、jsonb等类型会直接报错，例如：function string_agg(integer, text) does not exist。它不会自动调用隐式类型转换。
常见修复方式：
- 用
::text后缀：STRING_AGG(id::text, ', ' ORDER BY id) - 用
CAST()函数：STRING_AGG(CAST(user_id AS TEXT), '; ' ORDER BY user_id) - 对
uuid字段，uuid::text最稳妥；对jsonb，需先jsonb_extract_path_text()再转文本
别指望CONCAT()兜底——STRING_AGG(CONCAT(col), ', ')不能绕过类型检查，错误照报。
分隔符为NULL会导致整个结果为NULL
传NULL作分隔符不是“用空字符串代替”，而是让整个STRING_AGG()结果变成NULL。比如STRING_AGG(name, NULL)永远返回NULL，哪怕所有name都非空。
这个行为容易被忽略，尤其在动态构造SQL时：
- 参数来自变量或配置项时，务必加
COALESCE(delimiter, ', ')兜底 - 空字符串
''是合法分隔符，表示无间隔拼接：STRING_AGG(tag, '' ORDER BY sort_order) - 若需条件化分隔符（如首尾不加），得用
ARRAY+array_to_string()组合，STRING_AGG()不支持该粒度控制
最常踩的坑是误以为“不传分隔符”可行——STRING_AGG(name)语法错误，第二个参数不可省略。
