优先选JSON_TABLE（19c+且结构固定）或APEX_JSON（12c低版本或需PL/SQL灵活处理）；前者SQL集成高效但路径敏感、不支持纯PL/SQL调用，后者兼容性强但需初始化且解析严格。

JSON解析选 APEX_JSON 还是 JSON_TABLE？看 Oracle 版本和结构复杂度

oracle 12c 引入了原生 json_table，19c 起大幅增强；apex_json 是 apex 自带的 pl/sql 工具包，不依赖数据库版本，但需要安装 apex（哪怕只用它的 json 功能）。如果你用的是 12.1–12.2，json_table 支持有限（不支持嵌套对象展开、路径通配符），基本只能靠 apex_json；19c+ 且数据结构固定、需 sql 集成时，json_table 更直接高效。

• JSON_TABLE 必须配合 SELECT 使用，不能在纯 PL/SQL 过程里“解析后取值”，要取单个字段还得包装成子查询
• APEX_JSON 可以在任意 PL/SQL 块中调用 parse() + get_number()/get_varchar2()，适合做条件判断、循环处理
• 如果 JSON 含数组且需展开为多行，JSON_TABLE 的 COLUMNS NESTED 语法比 APEX_JSON 手写循环解析更简洁——但注意 12.2 不支持 NESTED

用 JSON_TABLE 解析嵌套数组时，路径写错会静默返回空结果

这不是报错，而是查不到数据。常见原因是：路径大小写敏感（"items" ≠ "Items"）、漏写 $ 根节点、或对数组用了点号访问（$.items.name 错，应为 $.items[*].name）。

• 必须用 [*] 显式声明数组遍历，否则只取第一个元素
• 路径中含空格或特殊字符，要用双引号包裹键名：$.["order id"]
• 如果 JSON 中某个字段缺失，对应列返回 NULL，不会中断整个查询——这容易掩盖字段名拼写错误
• 示例：解析 {"data":[{"id":1,"tags":["a","b"]}]} 中所有 tag，得写 COLUMNS (tag VARCHAR2 PATH '$.tags[*]')，不是 '$.tags'

APEX_JSON 解析失败常因未初始化或 JSON 格式不严格

APEX_JSON.parse() 遇到非法 JSON（如尾部逗号、单引号字符串、NaN）会直接报 ORA-40441: JSON syntax error，而 JSON_TABLE 在 19c+ 默认宽容模式下可能容忍部分错误。

• 每次调用前必须先 APEX_JSON.initialize_clob_input() 或 parse(p_json)，重复 parse 同一个 CLOB 不清状态，会导致后续 get_* 取错层级
• 解析数组时，要用 get_count(p_path => 'items') 先确认长度，再用 for i in 1..n loop get_number('items[%d].id', i) —— %d 是唯一合法占位符，写 %s 或 {i} 会静默失败
• 如果 JSON 是 UTF-8 with BOM，APEX_JSON 可能解析异常，建议入库前用 UTL_RAW.cast_to_varchar2() 清除 BOM

性能差异集中在大 JSON 和高频调用场景

单次解析小 JSON（JSON_TABLE 在 SQL 层利用 C 语言解析器，通常快 2–5 倍；APEX_JSON 每次调用都有 PL/SQL 上下文切换开销。

• JSON_TABLE 支持谓词下推（WHERE jt.status = 'active'），能跳过不匹配的 JSON 文档；APEX_JSON 必须先全量解析再 PL/SQL 过滤
• 如果业务逻辑强依赖 PL/SQL（比如解析后要调用其他过程、发邮件、写日志），硬套 JSON_TABLE 反而增加中间表或临时变量负担
• 12.1 用户别试 JSON_TABLE 处理深层嵌套——它连 $.a.b.c[*].d 都可能报 ORA-40494，老实用 APEX_JSON

最麻烦的其实是混合场景：前端传来的 JSON 结构不固定，有的有 metadata，有的没有，有的 items 是数组，有的是单对象——这时候两个函数都得加防御性判断，JSON_EXISTS 和 APEX_JSON.does_exist() 得一起上，不然解析就崩。