SQL Server 2016+解析JSON应优先用JSON_VALUE提取单值、OPENJSON展开数组或对象；JSON_VALUE默认静默返回NULL，需加ERROR ON ERROR调试；OPENJSON必须配合WITH声明类型；JSON_QUERY用于保留子对象/数组结构；注意路径严格性、类型匹配及性能优化。
SQL Server 2016+ 中解析 JSON，优先用 JSON_VALUE 提取单个字段，用 OPENJSON 展开数组或对象为行集；别混用、别跳过类型声明、别忽略路径错误静默返回 NULL。
为什么 JSON_VALUE 返回 NULL 却不报错？
这是默认 strict mode 行为：路径不存在、类型不匹配、或值为 null，统统返回 NULL，而不是中断执行。调试时容易误判为“数据为空”，实际是路径写错了。
- 加
ERROR ON ERROR强制报错，开发阶段强烈建议加上，例如：JSON_VALUE(@json, '$.user.name' ERROR ON ERROR) - 路径必须以
$开头：'$.data.items[0].id'合法，'data.items[0].id'直接返回NULL - 如果目标值是数字但你声明了
NVARCHAR，SQL Server 会隐式转换；但如果 JSON 里是字符串"123"而你用INT提取，也会返回NULL
OPENJSON 解析数组时，WITH 子句必须显式声明列名和类型
不带 WITH 的 OPENJSON 只返回三列（key、value、type），无法直接映射业务字段。要转成结构化表，WITH 是必选项。
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
-
WITH中列名不一定要和 JSON key 一致，但类型必须合理匹配，比如 JSON 里的"age": 30应该映射为INT，不是VARCHAR(10) - 嵌套对象不能直接展开：若 JSON 有
"address": {"city": "NY", "state": "NY"}，不能在WITH里写city NVARCHAR(50) '$.address.city'—— 这是合法的，但要注意引号和点号位置 - 数组元素索引从 0 开始，
'$[0].title'才是第一个对象的title，别写成'$[1].title'
什么时候该用 JSON_QUERY 而不是 JSON_VALUE？
当你需要保留原始 JSON 结构（比如一个子对象或数组），而不是提取某个字符串/数字时，必须用 JSON_QUERY。用错会导致前端解析失败或双引号嵌套。
-
JSON_VALUE(@j, '$.items')返回NULL（因为items是数组，不是标量） -
JSON_QUERY(@j, '$.items')返回原样 JSON 数组，如[{"id":1},{"id":2}] - 如果把
JSON_QUERY结果拼进另一个 JSON 字段（如CONCAT('{ "data": ', JSON_QUERY(...), ' }')），它不会自动加外层引号，安全；而误用JSON_VALUE会把它当字符串处理，导致输出变成"[{\"id\":1}]"，前端JSON.parse()报错
性能与兼容性关键点
JSON_VALUE 和 OPENJSON 都要求数据库兼容级别 ≥ 130，且只支持 NVARCHAR 类型输入（哪怕源列是 VARCHAR，也得先 CAST）。多次调用 JSON 函数可能拖慢查询，尤其在 WHERE 条件中使用时。
- 避免在大表
WHERE中写JSON_VALUE(json_col, '$.status') = 'active'—— 没法走索引，考虑冗余字段或计算列 + 索引 -
OPENJSON是表值函数，可以和CROSS APPLY配合展开多层嵌套，但每层都增加解析开销 - 如果 JSON 数据来自外部 API，入库前用
ISJSON()校验，避免后续解析全崩：WHERE ISJSON(doc) > 0
最常被忽略的是路径表达式的严格性和类型匹配——它不报错，只沉默返回 NULL，而生产环境里这种“看似没数据”的问题最难定位。
