JSON_EXTRACT返回带引号的JSON字符串，必须用JSON_UNQUOTE剥离引号才能在子查询中正确比较；路径错误、字段非法或缺失均静默返回NULL，高频查询应建虚拟列+索引优化性能。
MySQL 8.0+ 中用 JSON_EXTRACT 配合子查询提取嵌套 JSON
MySQL 原生支持 JSON，但 JSON_EXTRACT 返回的是带引号的字符串（如 "value"），直接在子查询中参与比较或连接容易出错。必须用 JSON_UNQUOTE 剥离引号，否则 WHERE name = JSON_EXTRACT(data, '$.user.name') 永远不成立。
常见错误现象：子查询返回空结果，但手动查 JSON 字段明明有值；或者报错 Invalid JSON text —— 很可能是因为外层查询把未解包的 JSON 字符串当普通字符串用了。
-
JSON_EXTRACT(json_col, '$.a.b.c')返回"foo"（含双引号），不是foo - 需要写成
JSON_UNQUOTE(JSON_EXTRACT(json_col, '$.a.b.c'))才能用于等值匹配或IN子查询 - 路径表达式不支持变量拼接，
'$.items[' + idx + '].id'这种写法非法，得用JSON_TABLE或预处理生成 SQL
PostgreSQL 中用 -> 和 ->> 区分对象与标量，子查询里别混用
PostgreSQL 的 JSON 操作符语义更清晰：-> 返回 JSON 类型（可用于继续链式取值），->> 直接返回 TEXT。子查询中若要和其他字段做 = 或 JOIN，必须用 ->>，否则类型不匹配报错 operator does not exist: json = text。
使用场景：比如主表 orders 有个 meta JSONB 字段，想关联查出所有 meta->'shipping'->>'carrier' 对应的物流公司名称。
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
- 错误写法：
WHERE carrier_name = (SELECT meta->'shipping'->'carrier' FROM orders LIMIT 1)—— 返回的是 JSON，不是字符串 - 正确写法：
WHERE carrier_name = (SELECT meta->'shipping'->>'carrier' FROM orders LIMIT 1) - 多级存在性判断要用
?（key 存在）或@>（包含），不能只靠IS NOT NULL，因为meta->'a'->'b'即使b不存在也返回NULL，但meta ? 'a'才表示 keya确实存在
SQL Server 2016+ 中 OPENJSON 是唯一靠谱的多级展开方式
SQL Server 不支持类似 MySQL 的路径表达式嵌套取值，JSON_VALUE 只能取单层标量，且无法在子查询中直接展开数组。真正处理多级结构（尤其是数组内对象）必须用 OPENJSON 配合 WITH 子句显式定义 schema。
性能影响明显：对大 JSON 字段反复调用 OPENJSON 会触发多次解析，建议先用 CTE 提取顶层结构，再逐层展开。
- 错误思路：试图用多个
JSON_VALUE嵌套，如JSON_VALUE(JSON_VALUE(data, '$.items'), '$[0].id')—— 不合法，第二层JSON_VALUE参数必须是字符串，不是 JSON 值 - 正确做法：先
SELECT id, items_json = JSON_QUERY(data, '$.items') FROM raw，再对items_json调用OPENJSON -
WITH子句中路径写'$.name'表示从根开始，写'$.items[0].id'是合法的，但不能动态索引，[i]中的i必须是字面量
跨数据库通用陷阱：NULL 处理和空数组边界
所有数据库对缺失路径的返回都是 NULL，但空数组 [] 行为不同：MySQL 的 JSON_EXTRACT(json, '$.list[0].id') 在 list 为空时返回 NULL；PostgreSQL 的 meta->'list'->0->>'id' 则报错 cannot extract field from a scalar，因为 ->0 试图从空数组取第 0 项失败。
容易被忽略的地方是子查询作为 IN 或 = 右值时，如果子查询因路径不存在全返回 NULL，整个条件变成 col IN (NULL)，结果恒为 UNKNOWN，相当于没匹配到任何行 —— 这不是 bug，是三值逻辑的必然结果。
- 安全写法：MySQL 加
WHERE JSON_LENGTH(json_col, '$.path') > 0确保路径存在且非空 - PostgreSQL 加
AND jsonb_path_exists(meta, '$.path')（v12+）或用jsonb_typeof判断类型 - SQL Server 在
OPENJSON后加WHERE [key] IS NOT NULL过滤掉无效解析项
