MyBatis 查询 Oracle CLOB 字段返回 null 的根本原因是未显式指定 jdbcType=CLOB，导致驱动跳过 LOB 专用路径而回退到 getString() 或返回 null；必须在 #{} 和 <resultMap> 中强制声明 jdbcType=CLOB，或使用 java.sql.Clob 类型配合 getCharacterStream() 安全读取。
MyBatis 查询 Oracle 时 CLOB 字段返回 null，**不是数据丢了，而是类型映射失败或驱动未触发正确读取路径**。根本原因在于 MyBatis 默认不识别 CLOB 的特殊语义，既没指定 JDBC 类型，也没走安全流式读取，导致底层驱动悄悄回退到 getString() 或直接返回 null。
Mapper 中未显式声明 jdbcType=CLOB
Oracle 的 CLOB/BLOB 必须在 MyBatis 的 #{} 或 <result> 中显式标注 jdbcType=CLOB，仅靠 javaType=String 或字段类型推断完全无效。
-
#{content}→ 驱动按默认规则处理，可能转成getString()，而空值或超长内容时直接返回null -
#{content,jdbcType=CLOB}→ 强制走 LOB 专用路径，后续才能调用getCharacterStream() - 在
<resultMap>中也必须写：<result property="content" column="content" jdbcType="CLOB"/> - MyBatis-Plus 用户注意：
@TableField注解不支持jdbcType，必须配合resultMap或 XML 显式配置
实体类字段类型与 JDBC 处理逻辑冲突
CLOB 不能简单当 String 用——它本质是数据库服务端的一个 locator 句柄，不是内存字符串。MyBatis 在映射阶段若发现字段类型是 String 但 JDBC 类型是 CLOB，又没配 typeHandler，就可能跳过赋值直接留 null。
- 避免把 CLOB 字段声明为
String后“指望自动转”，这是最常见误判点 - 更稳妥的做法：声明为
java.sql.Clob，再在业务层用getCharacterStream()按需读取（见下一条） - 如果坚持用
String，必须自定义TypeHandler<String>，内部封装try-with-resources+getCharacterStream()，否则必踩 OOM 坑
驱动版本与隐式缓存干扰读取
Oracle 11g 早期 JDBC 驱动（如 ojdbc6）中，clob.length() 本身就会触发全量 fetch；而 MyBatis 默认的 DefaultResultHandler 在构建结果时可能无意调用了该方法。
- 现象：SQL 执行成功、日志显示有数据，但 CLOB 字段始终为
null，且 GC 日志出现突发堆内存增长 - 验证方式：关闭连接池的 implicit caching（
implicitCachingEnabled=false），并升级到ojdbc8或更高 - 关键配置（DataSource 层）：
connectionProperties=oracle.jdbc.defaultRowPrefetch=100;implicitCachingEnabled=false - 永远不要在 MyBatis 的
resultMap或typeHandler里调用clob.length()或clob.getSubString()
真正安全的读取只有一条路径：用 getCharacterStream() + try-with-resources + 小缓冲区循环读取。任何试图“一步转 String”的操作，都在赌内存和驱动行为——而 Oracle LOB 的设计本意就是拒绝这种赌法。
