SQL Server存储过程处理JSON核心是JSON_VALUE和OPENJSON：前者用于快速提取单个标量值，后者用于结构化解析数组或对象；必须用NVARCHAR输入，先ISJSON验证，避免循环解析和裸用JSON_VALUE查索引。
SQL Server 存储过程中处理 JSON，核心就两条路：简单提取用 JSON_VALUE，结构化解析用 OPENJSON。别想着先转成表再操作——SQL Server 不支持直接把 JSON 当表用，必须靠这两个函数“撬开”。
什么时候该用 JSON_VALUE 而不是 OPENJSON
当你只需要从单个 JSON 字符串里捞一两个字段（比如 '$.name'、'$.order_id'），且确定它总是一个对象（不是数组）、字段值是标量（字符串/数字/布尔），就直接上 JSON_VALUE。它快、轻量、不依赖 WITH 子句定义结构。
- 如果路径不存在或值是非标量（比如想取
'$.tags'但它是数组），JSON_VALUE返回NULL，不会报错 - 返回值默认是
NVARCHAR(4000)，若字段可能超长，显式转成NVARCHAR(MAX)，例如CAST(JSON_VALUE(@json, '$.desc') AS NVARCHAR(MAX)) - 别在
WHERE条件里裸用JSON_VALUE做等值匹配——没索引时全表扫描解析，性能崩得快；真要查得勤，考虑用计算列 + 索引
OPENJSON 必须配 WITH 子句才能用吗
不是必须，但强烈建议配。不带 WITH 的 OPENJSON(@json) 只返回三列：key、value、type，全是字符串，你得自己 CAST 和判断类型，极易出错。
- 带
WITH才能映射成真正可用的列，例如name NVARCHAR(100) '$.name'，SQL Server 会自动按声明类型转换并截断 - 路径支持嵌套，比如
addr_city NVARCHAR(50) '$.address.city'，但注意：只要中间任一层为NULL，整条记录该字段就是NULL - 如果 JSON 数组里某些对象缺字段，对应行该列就是
NULL，不会跳过那行——这是正常行为，不是 bug
在存储过程中循环处理 JSON 数组的常见陷阱
很多人想用 WHILE 配 JSON_VALUE 模拟循环取数组元素，这非常脆弱。正确姿势是让 OPENJSON 直接展开数组，交给 SQL 引擎做集合操作。
-
OPENJSON默认把输入当作 JSON 对象；若传入的是数组（如N'[{"id":1},{"id":2}]'），它也能展开成两行——前提是调用时不加根路径参数，即OPENJSON(@json)而非OPENJSON(@json, '$.items') - 若数组藏在对象下（如
{ "data": [...] }），必须写完整路径：OPENJSON(@json, '$.data')，否则只解析外层对象 - 别在循环里反复调用
OPENJSON解析同一段 JSON——每次调用都重新解析全文，CPU 白烧；一次性展开，再用INSERT ... SELECT或临时表承接结果
ISJSON 验证和错误处理不能省
存储过程里接收外部传入的 JSON，第一件事必须是验证有效性。ISJSON(@input) 返回 0 就立刻 RETURN 或抛异常，别往后走。
-
ISJSON只检查语法，不保证语义合理（比如数字字段存了字符串）；业务逻辑层仍需对关键字段做TRY_CAST防御 -
OPENJSON遇到非法 JSON 会直接报错中断执行，而JSON_VALUE在非法输入时静默返回NULL，容易掩盖问题 - 调试时把原始 JSON 截断打印出来很麻烦，建议在存储过程开头加一句：
IF @debug = 1 PRINT LEFT(@json, 200) + '...'，比盲目猜强得多
最易被忽略的一点：SQL Server 的 JSON 函数全部基于 UTF-16 编码，所有输入必须是 NVARCHAR。传入普通 VARCHAR 字符串会导致中文乱码或 ISJSON 返回 0——这点在从旧系统迁移或拼接动态 SQL 时特别致命。
