string_agg结果被截断主因是隐式类型转换触发8000字节限制，需显式cast为text或varchar(max)规避；order by必须内置于函数中（pg用“, delimiter order by”、sql server用“within group”）；全null组返回null，须用coalesce兜底。
STRING_AGG结果被截断，不是数据丢了，是类型隐式转换卡了8000字节
PostgreSQL 和 SQL Server 的 STRING_AGG 本身不限长，但实际返回被截成 8000 字节左右，根本原因是输入表达式类型触发了隐式转换上限：比如传入 varchar(2000) 字段，或未显式声明大类型，最终结果被转成 varchar(8000) 或 nvarchar(4000) ——超长部分直接丢弃，不报错也不警告。
- 查当前返回类型：
SELECT pg_typeof(STRING_AGG(col, ',')) FROM t;，常看到是text（PG）或varchar(8000)（SQL Server） - SQL Server 中必须用
CAST(col AS VARCHAR(MAX))或CAST(col AS NVARCHAR(MAX))强制升级为 LOB 类型，否则哪怕总长 100 字符、单字段就 5000 字节，也会被截断 - PostgreSQL 里
text类型本无长度限制，但如果上游字段是varchar(n)且 n ≤ 8000，聚合后仍可能受 planner 优化影响产生意外截断；稳妥做法是统一CAST(col AS TEXT) - 不要依赖“看起来够长”，比如
varchar(10000)在某些版本中仍会被降级处理；直接上TEXT或MAX最省心
为什么加了ORDER BY还是不稳定？顺序控制没写对位置
在 PostgreSQL 和 SQL Server 中，ORDER BY 必须嵌在 STRING_AGG 函数内部，且语法位置严格——写错地方等于没写，结果依然随机。
- PostgreSQL 正确写法：
STRING_AGG(col, ',' ORDER BY id)，ORDER BY是分隔符后的独立子句，不能塞进参数里，也不能提出来放外面 - SQL Server 正确写法：
STRING_AGG(col, ',') WITHIN GROUP (ORDER BY id)，WITHIN GROUP是固定前缀，不可省略，且只能跟一个ORDER BY表达式列表 - 常见错误：写成
STRING_AGG(col, ',') ORDER BY id（外部排序），这只会对最终结果集排序，不影响拼接顺序 - 多字段排序要写全：
ORDER BY status NULLS LAST, created_at DESC，漏掉NULLS LAST可能导致 NULL 值排在前面，和预期不符
全为NULL时返回NULL，不是空字符串——这是最隐蔽的崩点
STRING_AGG 对单个 NULL 值默认跳过，没问题；但当某组内所有值都是 NULL，它返回的是 NULL，不是空字符串。上游代码若只判 IS NULL 或 COALESCE(..., '') 没包住整个聚合表达式，就会直接出错。
- 安全写法永远是：
COALESCE(STRING_AGG(col, ','), '')，把整个函数结果兜底 - 如果想把
NULL显式转成占位符（如'(null)'），得先用COALESCE(col, '(null)')再聚合，而不是反过来 - SQL Server 中可用
ISNULL(STRING_AGG(...), '')，但注意ISNULL只支持两个参数，且类型需匹配 - 别信“我这组肯定有值”，JOIN 条件失败、过滤条件太严、字段被误设为 NOT NULL 实际却为空，都可能导致整组为 NULL
跨数据库迁移时，GROUP_CONCAT 和 STRING_AGG 别硬套参数顺序
MySQL 的 GROUP_CONCAT(col SEPARATOR ',') 和 PostgreSQL/SQL Server 的 STRING_AGG(col, ',') 看似一样，但参数顺序相反、默认行为不同，直接替换必出问题。
- MySQL 中分隔符是关键字
SEPARATOR后的值；PG/SQL Server 中是第二个必需位置参数，写反了会报错或静默失败 - MySQL 默认长度 1024，PG/SQL Server 不限长但受类型限制；别以为调了
group_concat_max_len就能在 PG 里起效 - MySQL 支持
GROUP_CONCAT(DISTINCT col)直接去重；SQL Server 支持STRING_AGG(DISTINCT col, ',')；但 PostgreSQL 不支持DISTINCT关键字，得靠子查询或DISTINCT ON预处理 - 迁移时最保险的做法：先确认目标库版本（如 SQL Server STRING_AGG），再逐字段检查参数位置、NULL 处理、排序语法是否匹配
