dbms_lob.read读取blob必须先调用dbms_lob.open(v_blob, dbms_lob.lob_readonly)，否则报ora-22275；offset从1起算，amount为字节数且≤32767，需用raw(32767)接收并手动维护offset累加。
DBMS_LOB.READ 读取 BLOB 必须先 OPEN，否则报 ORA-22275
直接对未打开的 BLOB 定位器调用 DBMS_LOB.READ 会触发 ORA-22275: invalid LOB locator specified。这不是数据为空的问题，而是 LOB 句柄处于“未就绪”状态。
正确流程必须显式 OPEN → READ → CLOSE，尤其在循环读取大文件时容易漏掉 CLOSE，导致后续操作失败或会话级 LOB 句柄泄漏。
-
DBMS_LOB.OPEN(v_blob, DBMS_LOB.LOB_READONLY)是必需前置步骤，哪怕只读一次 - 读取缓冲区建议用
RAW(32767)类型变量，避免隐式转换开销 -
offset参数从 1 开始（不是 0），且不能超过DBMS_LOB.GETLENGTH(v_blob)返回值 - 若需分块读，每次
amount建议设为 32767（PL/SQL RAW 最大长度），并手动维护offset累加
WRITE 写入 BLOB 前必须用 CREATETEMPORARY 或 SELECT ... FOR UPDATE
BLOB 字段插入后不能直接写入字节——它只是一个定位器（locator），背后没有可写的存储空间。常见错误是直接对刚 INSERT INTO t (blob_col) VALUES (empty_blob()) 的行执行 DBMS_LOB.WRITE，结果静默失败或报 ORA-22285。
两种合法路径：
- 用
DBMS_LOB.CREATETEMPORARY(v_blob, TRUE)创建可读写临时 BLOB，适合内存中拼装、加密、截断等中间处理 - 对已存表记录，必须先
SELECT blob_col INTO v_blob FROM t WHERE id = ? FOR UPDATE，再DBMS_LOB.WRITE，否则写入不生效 - 注意：临时 BLOB 不进事务日志，
COMMIT后自动释放；而表中 BLOB 的写入必须在事务内完成 -
DBMS_LOB.WRITE的amount是字节数，offset从 1 起算，且不能越界（超过当前长度会自动扩展）
GETLENGTH 返回 NULL 时别直接参与数值运算
DBMS_LOB.GETLENGTH 对 NULL BLOB 返回 NULL，不是 0。如果后续用它做循环条件（如 WHILE i ），整个循环会被跳过，且不报错。
安全写法永远加 NVL：
DECLARE
v_len INTEGER;
BEGIN
v_len := NVL(DBMS_LOB.GETLENGTH(v_blob), 0);
IF v_len > 0 THEN
-- 安全进入处理逻辑
END IF;
END;
- 不要依赖
v_blob IS NOT NULL判断是否有内容——empty_blob() 返回非 NULL 但长度为 0 - 区分 NULL（无 locator）、empty（有 locator 但无数据）、有数据三者状态，用
DBMS_LOB.GETLENGTH+IS NULL组合判断最稳 - 大量小 BLOB 场景下，频繁调用
GETLENGTH有轻微解析开销，可缓存一次结果复用
并发写入同一 BLOB 行要防覆盖，别依赖默认隔离级别
多个会话同时对同一行 BLOB 执行 SELECT ... FOR UPDATE + WRITE，Oracle 默认只锁行，不锁 LOB 段。若两个会话都读到原始长度 L，各自写入不同偏移，可能造成字节交错或静默截断。
真实生产中必须加应用层协调：
- 用
SELECT ... FOR UPDATE NOWAIT配合异常捕获，避免死锁等待 - 写入前先
DBMS_LOB.TRIM(v_blob, 0)清空，再整体重写，比追加更可控 - 高并发场景建议改用临时表 +
DBMS_LOB.COPY替换整字段，原子性强 - 千万别在存储过程中裸跑多线程（如
DBMS_SCHEDULER并发 job 写同一 BLOB 行），这是典型的数据损坏温床
实际最难缠的从来不是函数怎么调，而是 NULL / empty / 已提交未刷新 / 并发定位器冲突这四类边界状态混在一起时，错误表现极其隐蔽。写完务必用 DBMS_LOB.GETLENGTH 和十六进制校验（如 RAWTOHEX(DBMS_LOB.SUBSTR(...))）交叉验证结果。
