根本原因是dbms_lob.substr()强制将clob转为varchar2，受4000字节上限约束（oracle 10g/12c默认），超长即报ora-06502；应控制长度≤4000，或改用dbms_lob.read+utl_raw.cast_to_varchar2分段读取，或在应用层处理clob流。
DBMS_LOB.SUBSTR(CLOB) 调用报 ORA-06502 怎么办
根本原因不是 CLOB 本身出错，而是 DBMS_LOB.SUBSTR() 强制把 CLOB 截成 VARCHAR2，而这个返回值受当前环境 VARCHAR2 长度上限约束（Oracle 10g 是 4000 字节，12c+ 默认仍是 4000，除非在 PL/SQL 块中显式启用 extended VARCHAR2）。
常见错误写法：SELECT DBMS_LOB.SUBSTR(my_clob, 5000, 1) FROM dual —— 第二个参数 5000 直接超限，立刻崩。
- 查清你的 Oracle 版本和是否启用 extended data types：
SELECT * FROM V$VERSION；再查SELECT VALUE FROM V$PARAMETER WHERE NAME = 'max_string_size'（EXTENDED才支持 PL/SQL 内 32767 字节VARCHAR2） - 安全做法：始终把长度参数控制在 4000 以内，例如
DBMS_LOB.SUBSTR(clob_col, 4000, 1) - 若真需拼回长字符串，别用多次
SUBSTR拼接，改用DBMS_LOB.READ()+UTL_RAW.CAST_TO_VARCHAR2()分段读取，或直接在应用层处理 CLOB 流
函数返回 CLOB 却在 SQL 中直接 SELECT 报 ORA-06502
典型场景：你把一个原返回 VARCHAR2(4000) 的函数（比如 func_fa_getUNorOrgPath）改成返回 CLOB，但调用它的 SQL 没做适配，比如：SELECT func_fa_getUNorOrgPath('123') FROM dual。Oracle 会尝试隐式转 CLOB → VARCHAR2，触发 ORA-22835 或二次 ORA-06502。
- SQL 层级无法直接“显示”完整 CLOB（尤其在 SQL*Plus / TOAD 等工具里），它会自动截断或报错
- 验证是否真返回 CLOB：
DESC func_fa_getUNorOrgPath，确认返回类型是CLOB，不是STRING（后者仍是 VARCHAR2） - Java 或 .NET 应用必须用对应 CLOB API 读取（如 JDBC 的
ResultSet.getClob()+getCharacterStream()），不能用getString() - 临时调试可用：
SELECT DBMS_LOB.SUBSTR(func_fa_getUNorOrgPath('123'), 4000, 1) FROM dual，但仅限查看前段
PL/SQL 里拼 CLOB 时用 || 还是 DBMS_LOB.WRITEAPPEND
答案很明确：|| 是陷阱，DBMS_LOB.WRITEAPPEND 是正解。哪怕两边都是 CLOB，a || b 在 PL/SQL 中仍返回 VARCHAR2，一旦结果 > 4000 字节，立刻 ORA-06502。
- 错误示范：
l_clob := l_clob || 'some long text';—— 这行就可能崩，且每次执行都复制整个 LOB 内容，性能雪崩 - 正确流程：先
DBMS_LOB.CREATETEMPORARY(l_clob, TRUE)，循环中用DBMS_LOB.WRITEAPPEND(l_clob, LENGTH(part), part)，最后DBMS_LOB.FREETEMPORARY(l_clob) - 注意 NULL：任何参与拼接的变量必须
NVL(var, '')处理，否则整条 CLOB 变成 NULL，不报错但逻辑失效 - 如果拼接源含中文，用
LENGTHB()判断字节数，避免在 AL32UTF8 下因 3 字节/汉字误判长度
视图或查询里 SELECT CLOB 字段直接报 ORA-06502
这不是数据问题，是客户端或中间层试图把 CLOB 当成字符串渲染导致的。比如报表工具、旧版 JDBC 驱动、甚至某些 IDE 的结果网格，默认调用 getString() 尝试加载全部内容到内存。
- 最轻量解决：在 SQL 层截断，如
DBMS_LOB.SUBSTR(remark_clob, 2000, 1) AS remark，长度按实际业务需要设（1000、2000 更稳妥） - 更彻底方案：修改视图定义，对 CLOB 字段加
CAST(... AS VARCHAR2(4000))（Oracle 12.2+ 支持），但会丢失超长部分 - 别碰
WHERE clob_col LIKE '%xxx%'—— 全表扫描 + 隐式转换，极易触发 ORA-06502；改用DBMS_LOB.INSTR()函数索引或全文索引 - 真正要保留完整 CLOB，就得接受它不能“直接显示”，所有下游必须按 CLOB 接口处理，这是设计契约，不是 bug
CLOB 不是放大版 VARCHAR2，它是独立类型，有自己的一套生命周期和访问规则。最容易被忽略的是：DBMS_LOB.CREATETEMPORARY 后漏掉 FREETEMPORARY，不会立即报错，但内存缓慢泄漏，几天后整个实例变慢甚至 OOM。
