在使用 SQL Server 的 `JSON_VALUE` 函数时，许多开发者都会遇到一个“看似正常却总返回 NULL”的困惑——明明 JSON 结构看起来没问题，路径也写对了，为什么取不到值？其实，这背后藏着几个容易踩的坑，本文将一次性为你解析清楚，助你避免踩坑。

JSON_VALUE 无法直接提取多层嵌套对象？显式路径语法是关键

`JSON_VALUE` 函数的核心职责是返回标量值（如字符串、数字、布尔值或 null），对于对象或数组则直接忽略。如果你写了 `JSON_VALUE(json_col, '$.data')`，而 `$.data` 是一个对象，函数不会报错，而是静默返回 NULL，这极易让开发者误以为数据缺失。 要获取嵌套字段，必须写出完整路径，例如 `$.data.user.profile.name`。路径是大小写敏感的，且中间层级不能省略。以下示例说明： - 常见错误写法：`JSON_VALUE(json_col, '$.data')`（假设 data 是对象）→ 返回 NULL - 正确路径写法：`JSON_VALUE(json_col, '$.data.user.name')`（直达叶子节点） - 如果字段名包含空格或特殊字符，务必用双引号包裹：`'$.["user info"].email'`

处理 JSON 数组元素需借助 OPENJSON，JSON_VALUE 单独无法胜任

`JSON_VALUE` 对数组索引的支持非常有限：仅允许使用静态下标如 `[0]`，且要求路径最终指向标量值。例如 `'$.items[0].price'` 可以正常工作，但 `'$.items[1]'` 如果数组长度不足，函数会静默返回 NULL，没有任何错误提示，完全依赖开发者自行排查。 当需要遍历数组或动态获取索引时，必须改用 `OPENJSON` 配合 `WITH` 子句。例如，从 `$.orders` 数组中提取每个订单的 `id` 和 `status`： ```sql SELECT j.id, j.status FROM your_table CROSS APPLY OPENJSON(json_col, '$.orders') WITH ( id VARCHAR(20) '$.id', status VARCHAR(20) '$.status' ) AS j ```

NULL 值与缺失字段行为静默，建议先用 ISJSON 验证再使用 JSON_VALUE

`JSON_VALUE` 函数在输入非 JSON 字符串、路径不存在或目标非标量时，均统一返回 NULL。开发者无法仅凭结果判断是真正的 null 值还是路径错误。更隐蔽的是，如果列中存储的是普通字符串（例如 `'{a:1}'`，缺少引号），`ISJSON()` 返回 0，但 `JSON_VALUE` 依然静默返回 NULL，不产生任何错误信息。 - 安全实践：先通过 `WHERE ISJSON(json_col) = 1` 过滤有效 JSON - 调试时，临时输出原始 JSON 列 `json_col`，确认结构是否匹配预期路径 - 路径错误时，`JSON_VALUE` 不报错、不警告，仅返回 NULL——这是最容易被忽视的陷阱

性能注意事项：JSON_VALUE 为运行时解析，避免在 WHERE 中对大字段反复调用

每次调用 `JSON_VALUE` 都会重新解析整个 JSON 字符串。如果在 `WHERE` 或 `JOIN` 条件中多次使用（例如 `WHERE JSON_VALUE(col,'$.a') = 'x' AND JSON_VALUE(col,'$.b') > 10`），SQL Server 可能会对同一列进行多次重复解析。 - 优化方案：使用 `CROSS APPLY` 提前解析一次，生成计算列后再引用 - 或者将常用字段持久化为计算列并添加索引：`ALTER TABLE t ADD name AS JSON_VALUE(data, '$.user.name') PERSISTED` - 注意：`PERSISTED` 计算列要求 `JSON_VALUE` 表达式具有确定性，且仅 SQL Server 2016 及以上版本支持 总结核心要点：`JSON_VALUE` 的路径必须精确指向叶子标量，且对无效输入静默返回 NULL。实际编写查询时，建议先用 `ISJSON` 和原始字段内容进行交叉验证，这比反复猜测路径要高效得多。