DBMS_LOB.READ 读 CLOB 时 offset 和 amount 必须按字符计算，offset 从 1 开始为字符位置，amount 为字符数；AL32UTF8 下中文占 3 字节但算 1 字符，误用字节会导致乱码或 ORA-24801。
DBMS_LOB.READ 读 CLOB 时 offset 和 amount 怎么算
必须按字符算，不是字节。CLOB 的 offset 从 1 开始，是字符位置；amount 是要读的字符数。比如数据库字符集是 AL32UTF8，一个中文占 3 字节，但只算 1 个字符——传 amount := 10 就是读 10 个字符，不管底层多少字节。
常见错误：把 CLOB 当 BLOB 用同一套逻辑，比如用 LENGTHB('中文') 得到 6，再传给 DBMS_LOB.READ 的 amount，结果只读 6 字节，可能卡在 UTF-8 中间字节，返回乱码或报 ORA-24801。
- 读前先确认字符集：
SELECT * FROM NLS_DATABASE_PARAMETERS WHERE PARAMETER = 'NLS_CHARACTERSET' - 单次读取不能超 32767 字符（
VARCHAR2上限），超长必须循环分块读 - 别直接对空
CLOB变量调DBMS_LOB.READ，会报ORA-22285或静默失败
向 CLOB 写入前必须初始化，否则 WRITE_APPEND 失败
声明 clob_var CLOB ≠ 拥有一个可写的 LOB 实例。它只是空 locator，直接调 DBMS_LOB.WRITE_APPEND 不会报错但也不写入任何内容，或者报 ORA-22285。
两种合法初始化方式：
- INSERT 场景：用
EMPTY_CLOB()占位，再SELECT clob_col INTO clob_var FROM t WHERE ... FOR UPDATE锁定行，之后才能写 - 临时 LOB 场景：显式调
DBMS_LOB.CREATETEMPORARY(clob_var, TRUE)，第二个参数TRUE表示启用缓存，推荐 - 千万别对刚
SELECT出来的CLOB调DBMS_LOB.OPEN(..., DBMS_LOB.LOB_READONLY)后再写——只读打开后WRITE_APPEND必报ORA-22289
DBMS_LOB.CONVERTTOBLOB 不转码，只做字节复制
这个函数名有严重误导性。DBMS_LOB.CONVERTTOBLOB 不做任何字符集转换，只是把 CLOB 的底层字节序列原样拷进 BLOB。如果数据库是 AL32UTF8，CLOB 里 “你好” 存的是 0xE4BDA0E5A5BD（6 字节），转出的 BLOB 就是这 6 字节。
下游系统若期望 GBK 编码（“你好” 在 GBK 是 0xC4E3BAC3，4 字节），直接用这个 BLOB 就会乱码。
- 真要转码，得先用
UTL_I18N.STRING_TO_RAW('你好', 'ZHS16GBK')得到目标编码的 RAW，再用DBMS_LOB.WRITE写入 BLOB -
CONVERTTOBLOB适合纯二进制场景（比如把文本当 raw data 存），不适合跨字符集迁移
长 CLOB 不能硬编码进 SQL，必须用绑定变量或分段处理
超过 4000 字符的字符串不能直接写在 SQL 里，否则触发 ORA-01704: string literal too long。PL/SQL 中变量上限是 32767 字节，但 CLOB 字段本身能存 4GB —— 这个容量差就是陷阱来源。
- INSERT/UPDATE 时，一律用绑定变量传入长字符串，不要拼 SQL
- 读取超长 CLOB 时，别指望
DBMS_LOB.SUBSTR(clob, 32767, 1)一次拿完；必须用循环 +DBMS_LOB.READ分批读，每次amount ≤ 32767 - Java 等客户端读 CLOB，优先用
getCharacterStream()或getSubString()，避免一次性加载到内存
实际操作中最容易被忽略的，是 CLOB 和 BLOB 在所有 DBMS_LOB 函数中单位规则完全不一致，且没有运行时校验——写错单位不会立刻报错，而是等数据出问题才暴露。
