必须用ResultSet.getClob()获取Clob对象再流式读取，而非getString()；因Oracle JDBC驱动对getString()有4000字节隐式截断，且不报错，而getClob()+getCharacterStream()分块读才能完整安全获取CLOB内容。
直接用 ResultSet.getString() 读 CLOB 必然被截断，不是 bug，是 JDBC 驱动的默认行为——Oracle 驱动对 getString() 有隐式长度限制（常见为 4000 字节），超长内容直接丢弃后半段。
为什么 getString() 会静默截断
Oracle JDBC 驱动（尤其是 ojdbc8 及更早版本）在调用 ResultSet.getString("col") 时，并不真正走 CLOB 路径，而是尝试将 LOB 内容“降级”为普通字符串处理。一旦字段实际内容超过驱动内置缓冲阈值（如 4000 字符），它就只取前 N 字节并静默截断，不报错、不警告。
- 现象：SQL 查询结果明明有 10 万字符，Java 打印出来只有前 4000 个左右
- 陷阱：
rs.wasNull()返回false，你以为数据完整，其实已被砍掉 - 根本原因：这不是数据库返回了截断数据，而是驱动在客户端做了“妥协式读取”
必须改用 getClob() + 显式判空与流式读取
绕过截断的唯一可靠路径是跳过字符串转换层，直连 CLOB 对象本身，并控制读取节奏。
- 先调
rs.getClob("content")，别用getString() - 立刻检查是否为
null：Clob clob = rs.getClob("content"); if (clob == null) { /* 处理 NULL */ } - 确认非空后，用
clob.getCharacterStream()获取Reader，再分块读（不要readLine()，CLOB 可能无换行） - 示例安全读法：
try (Reader reader = clob.getCharacterStream()) { char[] buf = new char[8192]; int n; while ((n = reader.read(buf)) != -1) { // 处理 buf[0..n)，例如写入 StringWriter 或输出流 } }
连接 URL 和驱动配置影响截断行为
某些 ojdbc 行为受连接参数隐式控制，不调整可能让 getClob() 也“变相截断”——比如触发缓存后导致后续流失效或读取不全。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
- 必须加
?implicitCachingEnabled=false，否则驱动可能缓存 LOB 内容并干扰流读取完整性 - 避免在调
getCharacterStream()前调clob.length()：旧版驱动中，length()会强制预加载整个 LOB，不仅慢，还可能因超限失败导致流不可用 - 如果用 HikariCP 等连接池，确保
connectionTimeout和idleTimeout足够长——流读取期间连接不能被池回收
MyBatis 场景下容易忽略的映射陷阱
MyBatis 默认的 ClobTypeHandler 会偷偷调 clob.getSubString(1, (int) clob.length())，这看似绕开了 getString()，但依然会因 length() 调用和全量加载导致截断或 OOM，尤其当 CLOB 实际超 2GB 时 getSubString() 直接抛 SQLException。
- 正确做法：Mapper XML 中显式声明
<result column="content" property="clobContent" jdbcType="CLOB" javaType="java.sql.Clob"/> - 实体类字段类型必须是
java.sql.Clob，不是String - 业务层拿到
Clob后，仍需自己调getCharacterStream()分块读——不能依赖 MyBatis 自动转
真正决定是否被截断的，从来不是 SQL 或数据库配置，而是你从 ResultSet 拿数据那一刻选的 API 路径。只要碰了 getString() 或没管好 Clob 生命周期，截断就在那里，不声不响。
