ora-22835报错是因to_char强制将clob转varchar2，而varchar2硬限4000字节；substr(clob,1,4000)无效，因返回仍是clob；唯一sql层安全截取方式是dbms_lob.substr。
不能直接用 TO_CHAR 转 CLOB，超过 4000 字节必报 ORA-22835 —— 这不是 bug，是 Oracle 的硬限制。
为什么 TO_CHAR(clob_column) 会报错？
Oracle 中 VARCHAR2 单值最大长度为 4000 字节（非字符数），而 TO_CHAR 是隐式强制转成 VARCHAR2。只要 CLOB 内容实际字节数 > 4000，就会触发 ORA-22835。注意：中文在 AL32UTF8 字符集下占 3 字节，所以 2000 个汉字就可能超限。
-
TO_CHAR不做截断，只做转换；失败即报错，不返回前 4000 字节 -
SUBSTR(clob_column, 1, 4000)无效 ——SUBSTR对 CLOB 返回仍是 CLOB，没解决类型问题 - SQL 层无法“安全扩容”
VARCHAR2，这是类型系统级约束
SQL 层安全截取：用 DBMS_LOB.SUBSTR
这是唯一能在纯 SQL 中可控提取 CLOB 片段的方法，返回 VARCHAR2 类型，且明确指定字节长度。
- 语法：
DBMS_LOB.SUBSTR(clob_column, length, offset)，length单位是字节，不是字符 - 安全上限建议设为 3999 或更低（留缓冲防多字节字符越界）
- 示例：
SELECT DBMS_LOB.SUBSTR(content, 3999, 1) FROM docs - 如果要拼接多段，需在应用层循环调用，SQL 本身不支持自动分页
Java 层读取 CLOB 必须用流，不能靠 ResultSet.getString()
很多 ORM（如 MyBatis、Hibernate）默认把 CLOB 映射为 String，但底层仍调用 getString() —— 这本质还是走 TO_CHAR 路径，一样崩。
- 正确做法：显式获取
Clob对象，再用getCharacterStream()读取 -
rs.getClob("content").getCharacterStream()→ 包装成BufferedReader逐行读 - 避免一次性加载全量到内存：对超大 CLOB，应边读边处理（如写文件、流式解析）
- MyBatis 中需配置
jdbcType="CLOB"，否则参数传入时也会被当VARCHAR2处理，导致ORA-01704
Union 场景下 CLOB 和 VARCHAR2 列对齐的坑
当两个查询用 UNION 合并，一列是 CLOB、另一列是 VARCHAR2，Oracle 会尝试隐式转成统一类型 —— 但 CLOB 无法自动降级为 VARCHAR2，直接报错。
- 必须手动对齐：把 VARCHAR2 列也转成 CLOB（用
TO_CLOB()），或把 CLOB 列截成 VARCHAR2（用DBMS_LOB.SUBSTR） - 错误写法：
SELECT clob_col FROM t1 UNION SELECT varchar2_col FROM t2 - 正确写法：
SELECT DBMS_LOB.SUBSTR(clob_col, 4000, 1) FROM t1 UNION SELECT varchar2_col FROM t2 - 如果业务允许，优先统一转 CLOB（
TO_CLOB(varchar2_col)），避免数据截断
真正麻烦的不是怎么转，而是谁来承担截断风险 —— 数据库层截断不可逆，应用层流式读又增加复杂度。多数情况下，该用 CLOB 就别硬转，该分表存就别堆字段，早期设计比补救更省力。
