json_query提取整个子对象时必须显式指定lax或strict模式，如json_query(json_col, 'lax $.user')；默认虽为lax，但部分数据库对空结果处理更严格，易返回null而非预期json。
JSON_QUERY 提取整个子对象时必须指定 'lax' 或 'strict' 模式
直接写 JSON_QUERY(json_col, '$.user') 在多数数据库里会返回 NULL，不是语法错，而是默认行为不匹配预期。MySQL 8.0+、Oracle、SQL Server 都要求显式声明路径解析模式：不加修饰符时，JSON_QUERY 默认用 lax 模式，但某些实现（如早期 MySQL）对顶层路径或空结果处理更严格，导致意外截断或返回 NULL。
实操建议：
- 始终显式写成
JSON_QUERY(json_col, 'lax $.user')或JSON_QUERY(json_col, 'strict $.user') -
lax模式在路径不存在时返回 NULL；strict模式会报错（如Invalid path expression），适合强校验场景 - 如果目标字段是数组（如
$.tags），JSON_QUERY仍能完整返回，但需确认该字段确实存为 JSON 类型——若只是 TEXT 字段，函数可能静默失败
别把 JSON_QUERY 和 JSON_EXTRACT 混用
常见错误是看到 JSON_EXTRACT(json_col, '$.user.name') 能取字符串，就以为 JSON_QUERY(json_col, '$.user') 也能“顺手”取子对象，结果发现返回的是带引号的字符串（如 "{"id":1}"）。这是根本性区别：JSON_EXTRACT 返回 JSON 值（自动转义），JSON_QUERY 才返回未转义的合法 JSON 子文档。
关键差异：
-
JSON_EXTRACT返回类型是字符串（含转义），不能直接参与 JSON 函数链式调用 -
JSON_QUERY返回类型是 JSON（MySQL 中为json类型），可继续传给JSON_CONTAINS、JSON_LENGTH等 - 若用
JSON_EXTRACT取整个对象，再想解析它，得先CAST(... AS JSON)，多一步且易出错
MySQL 8.0.22+ 的空值处理陷阱
在 MySQL 中，如果 $.user 对应的值是 null（JSON 里的 null，不是 SQL NULL），JSON_QUERY(json_col, 'lax $.user') 会返回 SQL NULL，而不是 JSON null。这会导致后续 JSON_CONTAINS 判断失效——因为你在查一个 NULL，不是 JSON null。
详细的 Three.js 3D 图形参考，涵盖场景设置、相机、几何体、材质、光照、动画、控制器、加载器、数学工具和调试。
绕过方法：
- 先用
JSON_TYPE(JSON_EXTRACT(json_col, '$.user')) = 'NULL'判断是否为 JSON null - 或改用
JSON_QUERY(json_col, 'strict $.user')并捕获错误（需存储过程或应用层兜底） - 更稳妥的做法是加 COALESCE：
COALESCE(JSON_QUERY(json_col, 'lax $.user'), JSON_OBJECT())，避免下游 JSON 函数因 NULL 报错
PostgreSQL 没有 JSON_QUERY，得换写法
如果你在 PostgreSQL 里搜 JSON_QUERY，会找不到函数——它用的是 jsonb_path_query 或 ->/->> 操作符。这不是兼容问题，是设计差异。
等效操作：
- 取整个子对象（JSONB 类型）：
data -> 'user'（返回 jsonb）或data ->> 'user'（返回 text，已转义） - 要严格路径匹配并支持通配：
jsonb_path_query(data, '$.user')，注意它返回 setof jsonb，需配合 LATERAL 或 LIMIT 1 - 若原数据是 json（非 jsonb），先
data::jsonb -> 'user'，否则->不可用
最常被忽略的是路径表达式里的引号和大小写：JSON 键名区分大小写，'$.User' 和 '$.user' 是两个路径；MySQL 还要求单引号包裹整个路径字符串，漏掉会直接报语法错。
