JSON_VALUE在视图中返回NULL的主因是源数据类型不符、JSON非法或路径错误；须验证列类型为NVARCHAR(MAX)、ISJSON()为1，并用JSON_QUERY确认路径有效。
视图里 JSON_VALUE 返回一堆 NULL，不是函数坏了，是源头数据或路径写错了。
JSON_VALUE 在视图中静默返回 NULL 的真实原因
SQL Server 和 Oracle 支持在视图里直接用 JSON_VALUE，但前提是源列类型必须是 NVARCHAR(MAX) 或 JSON（Oracle 12c+），且内容是合法 JSON 字符串。常见踩坑点：
- 列定义为
VARCHAR(200)，但实际 JSON 长度超 300 字节 → 截断后不合法，JSON_VALUE返回NULL不报错 - 列类型是
TEXT或VARBINARY→ISJSON()永远返回 0，所有JSON_VALUE调用都失效 - 前端传入
{key: 1}（键没双引号）→ 看似像 JSON，实则非法，ISJSON()返回 0 - 字段含 BOM 头（如
\uFEFF{...}）或控制字符（\u0000）→JSON_VALID()（MySQL）或ISJSON()（SQL Server）会拒绝，但若跳过校验就直接进视图，结果仍是NULL
建视图前必须做的三件事
别急着写 SELECT JSON_VALUE(data, '$.user.name')，先验证底层数据是否“可解析”：
- 查长度和类型：
SELECT DATA_TYPE, CHARACTER_MAXIMUM_LENGTH FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = 'raw_table' AND COLUMN_NAME = 'json_col'，确认是nvarchar且长度为-1（即MAX） - 筛非法值：
SELECT TOP 10 json_col FROM raw_table WHERE ISJSON(json_col) = 0，把返回结果贴到 JSON 校验网站看哪出问题 - 测路径有效性：单独执行
SELECT JSON_VALUE(json_col, '$.user.name'), JSON_QUERY(json_col, '$.user')，用JSON_QUERY确认父路径是否存在，避免因嵌套层级错位导致全盘NULL
视图定义中如何安全封装 JSON 解析
直接裸写 JSON_VALUE 风险高，建议加兜底逻辑：
- 路径必须严格匹配大小写和结构：
JSON_VALUE(data, '$.user.profile.name')有效，'$.User.profile.name'或'$.user.profile["name"]'（SQL Server 不支持方括号）都会返回NULL - 显式处理空/错路径：
JSON_VALUE(data, '$.user.name' DEFAULT 'N/A' ON EMPTY, DEFAULT 'ERR' ON ERROR)，避免下游查询因NULL引发意外逻辑分支 - 性能敏感场景慎用多次调用：一个视图里写 5 个
JSON_VALUE，等于对每行 JSON 字符串解析 5 次；若需提取多个字段，优先考虑OPENJSON()（SQL Server）或JSON_TABLE()（MySQL 8.0+）一次性展开
修复已上线视图的 NULL 异常
线上视图已返回大量 NULL，不能只改视图定义——得同步清理源头：
- 先定位污染源：
SELECT COUNT(*) FROM my_view WHERE user_name IS NULL，再反查raw_table中对应行的ISJSON(json_col)值 - 批量修正非法 JSON：若问题集中在某几类格式错误（如单引号代替双引号、缺失大括号），可用
REPLACE+ 正则（SQL Server 2017+ 支持STRING_SPLIT配合条件拼接）清洗，但务必在从库验证后再跑生产 - 加约束防复发：对原始表加
CHECK (ISJSON(json_col) = 1)（SQL Server）或ADD CONSTRAINT valid_json CHECK (JSON_VALID(json_col) = 1)（MySQL），让后续插入自动拦截
最易被忽略的是：视图里的 NULL 往往不是解析失败，而是数据入库时就没校验——修复动作必须覆盖“存储层校验”“视图路径写法”“查询端默认值兜底”三层，缺一不可。
