dbms_lob.append比writeappend更适合追加场景，因其支持任意长度clob源、无需手动切片和for update锁定；但需确保目标clob已初始化且源clob cache=>true，临时clob须显式freetemporary。
DBMS_LOB.APPEND 比 WRITEAPPEND 更适合追加场景
直接用 DBMS_LOB.WRITEAPPEND 追加内容，容易踩两个坑：一是每次只能写 ≤32767 字节的 VARCHAR2，二是必须确保目标 CLOB 已初始化且被 SELECT ... FOR UPDATE 锁定。而 DBMS_LOB.APPEND 接收的是另一个 CLOB 变量，绕开了字符串字面量长度限制，也无需手动切片。
常见错误现象：写入 5MB 文本时反复调用 WRITEAPPEND，结果 PL/SQL 编译失败（PLS-00172）或运行时报 ORA-22922（LOB value nonexistent）。
- 必须先用
EMPTY_CLOB()占位 +SELECT ... FOR UPDATE获取可写句柄，否则APPEND会失败 - 源 CLOB 可以是临时的（
DBMS_LOB.CREATETEMPORARY创建），但cache => TRUE不可省，否则读不到内容 - 若源数据来自表中另一行 CLOB，直接传变量即可，比
WRITEAPPEND循环快 3–5 倍（实测 10MB 场景）
用 REGEXP_REPLACE 直接替换 CLOB 中的子串（不锁表、不写 PL/SQL）
REGEXP_REPLACE 是唯一能在纯 SQL 中安全操作 CLOB 内容的内置函数，它内部自动处理分段读取和拼接，不需要 FOR UPDATE 或临时变量。但要注意：它只适用于「全文搜索+替换」类需求，不能做偏移定位写入。
典型误用：试图在 UPDATE 里用 REPLACE(clob_col, 'old', 'new') —— 这会隐式转成 VARCHAR2，超 4000 字节就报 ORA-01704 或 ORA-22835。
- 语法必须是
REGEXP_REPLACE(clob_col, 'pattern', 'replacement')，第一个参数保持为 CLOB 类型 - 正则 pattern 若含特殊字符（如
"、\），需用双反斜杠转义，例如'"type":"OOC"'要写成'\"type\":\"OOC\"' - 性能影响：对单行 CLOB DBMS_LOB.INSTR/
DBMS_LOB.WRITE定位替换
替换大 CLOB 时避免 ORA-22835：别把 CLOB 当 VARCHAR2 用
所有试图用 TO_CHAR、UTL_RAW.CAST_TO_VARCHAR2 或隐式转换把整个 CLOB 拉进内存再处理的操作，都会触发 ORA-22835（缓冲区太小）。根本原因是 Oracle 的 VARCHAR2 限制仍是 32767 字节（12c+），而 CLOB 可达 GB 级。
错误示例：UPDATE t SET c = REPLACE(TO_CHAR(c), 'x', 'y') —— 即使 c 是 CLOB，TO_CHAR(c) 一执行就崩。
- 正确路径只有两条：走
REGEXP_REPLACE（推荐小到中等体积），或走DBMS_LOB.INSTR+DBMS_LOB.WRITE手动定位（大体积、高精度） - 用
DBMS_LOB.INSTR查找时，第三个参数是起始位置，第四个是最大搜索长度；别设成DBMS_LOB.LOBMAXSIZE，否则可能卡住 - 写入替换内容前，先
DBMS_LOB.ERASE原位置，再DBMS_LOB.WRITE新内容，避免残留字符
临时 CLOB 的生命周期管理常被忽略
用 DBMS_LOB.CREATETEMPORARY 构造中间 CLOB（比如拼接多个字段再写入表），最容易漏掉两件事：cache => TRUE 和 DBMS_LOB.FREETEMPORARY。漏前者会导致后续 READ 返回空；漏后者会让 PGA 内存持续增长，最终触发 ORA-04030。
真实故障现象：批量处理 1000 行 CLOB 后，会话 PGA 使用率从 20% 涨到 95%，后续任何 LOB 操作都变慢或失败。
-
DBMS_LOB.CREATETEMPORARY(v_clob, TRUE)中的TRUE是硬性要求，设FALSE等于白建 -
FREETEMPORARY必须在COMMIT前显式调用，不能依赖会话结束自动清理 - 如果用临时 CLOB 做源，往表中已有 CLOB 追加，必须用
DBMS_LOB.COPY，不能直接赋值table_clob := temp_clob
