Oracle写CLOB必须分两步：先INSERT EMPTY_CLOB()占位，再SELECT...FOR UPDATE获取句柄；写入需分段调用DBMS_LOB.WRITEAPPEND（≤32767字节/次），临时CLOB须CREATETEMPORARY并FREETEMPORARY。
直接用 INSERT INTO t(clob_col) VALUES ('...') 或 UPDATE 赋值超长字符串，必然触发 ORA-01704（字面量太长）或 ORA-22922（LOB 不存在），因为 Oracle SQL 层根本不允许在语句里硬编码超过 4000 字符的文本——CLOB 字段本身能存 4GB，但语法解析器卡在 4000 这道坎上。
写入必须分两步：占位 + FOR UPDATE 锁定
PL/SQL 中往表字段写 CLOB，不能跳过初始化。空 CLOB 不等于 NULL，它是个“句柄”，但没被锁定前无法写入。
-
INSERT INTO my_table(id, content) VALUES (123, EMPTY_CLOB())是必须的第一步，只为占位并生成可写句柄 - 紧接着必须执行
SELECT content INTO :clob_var FROM my_table WHERE id = 123 FOR UPDATE—— 缺少FOR UPDATE就会报ORA-22920 -
:clob_var是 PL/SQL 声明的CLOB类型变量，后续所有写操作都基于它
写入超长内容必须分段，每次 ≤32767 字符
DBMS_LOB.WRITEAPPEND 的第三个参数是 VARCHAR2，而 PL/SQL 中 VARCHAR2 最大就是 32767 字节（非字符数，注意多字节字符集下实际字符数更少）。一次性传入 10MB 字符串会直接编译失败或运行时报 PLS-00172。
- 推荐按 4000 或 8000 字符切片，避开 UTF-8 多字节截断风险
- 循环调用：
DBMS_LOB.WRITEAPPEND(:clob_var, LENGTH(slice), slice) - 如果源数据本身就是另一个 CLOB（比如从临时表读出），优先用
DBMS_LOB.COPY，比逐段读写快一个数量级，也避免字符集错位
读取时别用 getString()，也别 SELECT *
ResultSet.getString("content") 在 JDBC 中对 CLOB 是危险操作：驱动默认按 VARCHAR2 语义处理，超 4000 字节就返回 null 或静默截断，不是数据丢了，是协议没走通。
- 必须用
rs.getClob("content")，再判空：if (clob != null) { clob.getSubString(1, (int) clob.length()) } - 全量读取有 OOM 风险？改用流式：
clob.getCharacterStream()配合BufferedReader -
SELECT *会强制加载整个 CLOB 到内存，哪怕你只看前 10 行 ID。应显式列出非 LOB 字段，内容按需单查，或用DBMS_LOB.SUBSTR(clob_col, 200, 1)截取预览
临时 CLOB 必须手动管理生命周期
用 DBMS_LOB.CREATETEMPORARY 创建的 CLOB 不落盘，只存在 PGA 内存中，不释放就会累积导致 ORA-04030（PGA 耗尽）。
- 创建时
cache => TRUE是硬性要求，设FALSE后续DBMS_LOB.READ会读不到内容 - 写完必须调
DBMS_LOB.FREETEMPORARY(clob_var)，尤其在循环或长事务中容易漏掉 - 临时 CLOB 不能直接用于
INSERT INTO ... VALUES (:temp_clob)，得先DBMS_LOB.COPY到表中已存在的 LOB 句柄里
最易被忽略的是偏移单位：CLOB 的 DBMS_LOB.READ 和 WRITEAPPEND 中 offset 和 amount 都按“字符”计（从 1 开始），不是字节；而 BLOB 才按字节。混用会导致中文乱码或 ORA-24801，且这种错误往往只在特定字符组合下才暴露。
