string_agg不能直接替代group_concat，因二者参数强制性、null处理、默认分隔符及排序语法均不同：string_agg必须显式指定分隔符（无默认值），且order by须写在括号内；group_concat分隔符可选，默认逗号，order by紧贴字段后。
STRING_AGG 为什么不能直接替代 GROUP_CONCAT
PostgreSQL 没有 GROUP_CONCAT，但 STRING_AGG 是它的标准等价物——不过行为不完全一致。最常踩的坑是：MySQL 的 GROUP_CONCAT 默认忽略 NULL，而 PostgreSQL 的 STRING_AGG 会把 NULL 当作字符串字面量参与拼接（实际结果是跳过该值，但容易误判），更关键的是它**不自动去重、不内置分隔符默认值**，必须显式传参。
常见错误现象：ERROR: function string_agg(character varying) does not exist，这是因为只写了一个参数，而 STRING_AGG 至少需要两个：待聚合表达式和分隔符。
- 必须写成
STRING_AGG(column_name, ',')，不能省略第二个参数 - 如果想用空字符串做分隔符，得明确写
STRING_AGG(name, '') - 要跳过
NULL值？默认就跳，无需额外处理；但若字段本身存的是字符串'NULL'，就得用CASE过滤
怎么按分组合并多行字符串并控制顺序
无序拼接的结果不可预测——STRING_AGG 不保证行序，除非显式用 ORDER BY 子句。这个子句写在括号内，紧跟分隔符之后，用 ORDER BY 关键字，不是外面套 ORDER BY 查询级排序。
使用场景：比如合并一个用户的所有标签，要求按创建时间从前到后排列。
- 正确写法：
STRING_AGG(tag_name, ',' ORDER BY created_at) - 支持多字段排序：
STRING_AGG(tag_name, ',' ORDER BY priority DESC, id) - 注意：
ORDER BY里引用的字段必须在GROUP BY中出现，或为聚合字段，否则报错column "xxx" must appear in the GROUP BY clause - 性能影响：带
ORDER BY会触发内部排序，大数据量时可能变慢；如顺序不重要，删掉能提升吞吐
如何处理特殊字符和 SQL 注入风险
STRING_AGG 本身不转义内容，它只是把原始字符串连起来。如果你拼的是用户输入字段（比如评论、昵称），而后续又直接拼进 HTML 或 JS，就可能出问题——但这属于应用层职责，不是函数能解决的。
真正要注意的是：当分隔符或字段值含换行、制表符、逗号时，下游解析容易断裂。
- 安全做法：用非冲突分隔符，比如
STRING_AGG(name, '|||')，比逗号更可靠 - 需转义？自己套
REPLACE：STRING_AGG(REPLACE(name, ',', '\,'), ',')（但一般不推荐，改分隔符更简单） - 避免在
STRING_AGG里拼 SQL 片段（例如动态列名），那属于逻辑错误，应由应用构造完整语句
遇到长文本截断或内存溢出怎么办
PostgreSQL 默认对 STRING_AGG 结果长度不做限制，但实际受 work_mem 和总字符串长度影响。超长合并（比如几万行拼成一个大字符串）可能触发 ERROR: out of memory 或悄悄被截断（某些客户端显示不全）。
- 检查当前设置：
SHOW work_mem;，太小（如 4MB）时可临时调高：SET LOCAL work_mem = '16MB'; - 更稳妥的做法：在应用层分页聚合，或加
LIMIT子查询限制源行数 - 监控长度：用
LENGTH(STRING_AGG(...))辅助判断是否超出预期（比如 > 10000 字符就告警） - 注意：
STRING_AGG返回类型是text，理论上无长度限制，但客户端驱动或 ORM 可能有缓冲区上限
ORDER BY 必须写在函数括号内，以及分隔符参数不可省略——这两点导致的语法错误，在日志里往往只报“function does not exist”，而不是“missing argument”，排查时容易绕弯。
