必须使用DBMS_LOB.WRITEAPPEND配合CREATETEMPORARY与FREETEMPORARY实现CLOB流式拼接，因||强制返回VARCHAR2导致超4000字节必报ORA-06502或ORA-01489，且循环拼接引发内存爆炸。
超4000字节的字符串拼接在PL/SQL里根本不是“写法问题”，而是类型系统硬限制——VARCHAR2顶格4000字节，||运算符强制返回VARCHAR2，拼出来就崩。必须切到CLOB，且不能靠||硬扛。
为什么循环用 str := str || part 一定会内存爆炸？
每次||都新建一个VARCHAR2对象，旧内容全拷贝一遍。10万次拼接≈10万次内存分配+复制，PGA直接OOM。这不是慢，是不可行。
- 哪怕
part只有10字节，循环10万次后总长1MB，也早超出VARCHAR2上限 -
str初始为NULL时，str := str || 'a'结果仍是NULL，不报错但逻辑全错 - 所有参与字段必须显式
NVL(col, '')或COALESCE(col, '')，别指望数据库自动跳过
DBMS_LOB.WRITEAPPEND 才是唯一靠谱的流式拼接方式
它不复制已有内容，只在末尾追加，时间复杂度O(N)。但必须配对使用DBMS_LOB.CREATETEMPORARY和DBMS_LOB.FREETEMPORARY，漏掉后者会缓慢内存泄漏——下次执行可能因PGA不足静默失败。
- 先调
DBMS_LOB.CREATETEMPORARY(l_clob, TRUE)创建可写临时CLOB - 循环中用
DBMS_LOB.WRITEAPPEND(l_clob, LENGTH(part), part)追加，part可以是VARCHAR2或CLOB - 拼完必须调
DBMS_LOB.FREETEMPORARY(l_clob)，否则下次执行可能卡住 - 目标
CLOB变量初始化必须非NULL，否则WRITEAPPEND直接报错
LISTAGG 超长怎么办？ORA-01489 不是bug是设计
LISTAGG默认输出VARCHAR2，超过4000字符就报ORA-01489。12c+支持ON OVERFLOW TRUNCATE，但截断不解决数据丢失；真要保全，得手动转CLOB：
- 用
XMLAGG+XMLELEMENT组合，结果转CLOB再TRIM，绕过长度限制 - 或者分组后逐批
LISTAGG，再用DBMS_LOB.WRITEAPPEND拼起来（适合动态分隔场景） -
LISTAGG的ON NULL ''子句比||安全得多，但仅限聚合场景，不能替代流式拼接
插入超长字符串时ORA-01704怎么破？
这是SQL层字面量限制（4000字节），跟PL/SQL拼接无关。直接写INSERT INTO t(clob_col) VALUES ('...超长字符串...')必报错。
- 改用绑定变量：
INSERT INTO t(clob_col) VALUES (:clob_val)，应用层传CLOB对象 - 或在PL/SQL块里构造
CLOB再插入：l_clob := '...'; INSERT INTO t(clob_col) VALUES (l_clob); - 绝对不要在SQL里拼接用户输入，
WHERE col1 || col2 = ?会让索引失效，执行计划变全表扫描
最常被忽略的点：临时CLOB没配对FREETEMPORARY，问题不会立刻暴露，而是随时间推移PGA耗尽，最终整个会话卡死——这种故障没有错误日志，只有缓慢恶化。
