LISTAGG 默认返回 VARCHAR2 且超 4000 字节报 ORA-01489，必须配合 ON OVERFLOW RETURNING CLOB 或 CAST 转 CLOB，且语法顺序严格；基础写法须含 GROUP BY 和 WITHIN GROUP(ORDER BY ...)；XMLAGG 是兼容性更优的备选方案。
LISTAGG 默认只返回 VARCHAR2，超 4000 字节直接报 ORA-01489 中断执行——你不能靠“加个 TRUNCATE”就高枕无忧，必须从类型、版本、语义三方面同时控制。
LISTAGG 基础写法必须带 GROUP BY 和 WITHIN GROUP
裸写 SELECT LISTAGG(name, ',') 会报 ORA-00937；漏掉 WITHIN GROUP (ORDER BY ...) 则报 ORA-30496。这不是可选语法糖，是强制约束。
- 分组字段（如
dept_id）必须显式出现在SELECT和GROUP BY中，不能用别名替代 -
ORDER BY子句里的列，要么在SELECT列表里，要么在GROUP BY里，否则 Oracle 拒绝解析 - 哪怕不关心顺序，也得写
ORDER BY 1或ORDER BY dept_id；ORDER BY NULL虽能过语法检查，但结果不可重现
ON OVERFLOW 不是救命稻草，四个选项行为天差地别
12cR2+ 支持 ON OVERFLOW，但选错等于主动丢数据。它不改变返回类型，只决定溢出时怎么“善后”：
-
ON OVERFLOW ERROR：默认行为，报 ORA-01489 并终止整个查询 —— 适合强一致性场景，但下游必须能捕获异常 -
ON OVERFLOW TRUNCATE '…'：截断后加省略号，但', …'本身占 3 字节，实际可用空间 ≤ 3997 -
ON OVERFLOW TRUNCATE（无参数）：静默截断，不报错、不提示、不标记 —— 数据被砍了你也发现不了 -
ON OVERFLOW NULL：整组结果变NULL—— 仅当下游逻辑明确依赖空值判溢出时才可用
注意：ON OVERFLOW 后必须紧跟 RETURNING CLOB 才能突破 4000 限制，且 RETURNING CLOB 必须紧贴 ON OVERFLOW，顺序错一个字（比如写成 ON OVERFLOW RETURNING CLOB TRUNCATE）就报错。
真要突破 4000 字节，必须让 LISTAGG 返回 CLOB 类型
光加 ON OVERFLOW 不够，目标字段或表达式类型仍是 VARCHAR2，插入或赋值时照样卡住。关键一步是显式转换：
- 正确写法：
CAST(LISTAGG(...) AS CLOB)或LISTAGG(...) ON OVERFLOW ERROR WITH COUNT RETURNING CLOB - 错误写法：
TO_CLOB(LISTAGG(...))—— 它先在 VARCHAR2 内部拼完才转，超限时已报错，根本执行不到TO_CLOB - 如果 INSERT INTO 目标字段是
CLOB，但 SELECT 里没做类型转换，Oracle 仍按 VARCHAR2 处理，溢出照旧
当 LISTAGG 不可靠时，XMLAGG 是更稳的备选
尤其在 12.1 或更低版本，或需要跨版本兼容时，XMLAGG 天然返回 CLOB，无 4000 字节硬限，也不依赖 ON OVERFLOW 语法。
- 典型写法：
TRIM(',' FROM XMLCAST(XMLAGG(XMLELEMENT(E, emp_name || ',') ORDER BY emp_name) AS CLOB)) - 注意点：
XMLELEMENT生成的是带标签的 XML，必须用XMLCAST(... AS CLOB)提取纯文本，再用TRIM去掉末尾多余逗号 - 性能比 LISTAGG 略低，内存占用更高，但胜在稳定；若源字段含特殊字符（如
、<code>&），需先XMLSERIALIZE或DBMS_XMLGEN.CONVERT转义
最易被忽略的一点：无论用 LISTAGG 还是 XMLAGG，只要拼接结果可能超长，就必须在 SQL 编写阶段就决定类型策略和降级逻辑——上线后再补，往往查到一半就崩，没人替你背锅。
