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-jsapi-skill

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' 才表示 key a 确实存在

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 过滤掉无效解析项