正则不能可靠解析标准JSON，因其无法处理嵌套配对、转义字符、Unicode等语法特性；仅可在非纯JSON场景中粗略提取子串，后续必须用json_decode()验证和解析。
正则不能可靠解析标准 JSON，这是设计层面的硬限制，不是“技巧不够”或“写法不对”的问题。
为什么 preg_match 会错判 JSON 结构
JSON 允许任意深度嵌套、转义引号（"name": "A\"lice"）、Unicode 键名、空格/控制字符等。正则无法跟踪花括号/方括号的配对层级，也不能区分字符串内的 { 和结构起始的 {。
- 匹配
"id": 123可能误中{"id": "{\"x\":456}"}里的内层字段 - 遇到未闭合引号或
\u4f60这类 Unicode 转义时，preg_match()可能回溯爆炸或直接失败 - 数组项提取在
[{"a":1},{"b":2}]场景下必然漏掉第二项——正则没有“上下文感知”能力
哪些场景下可以谨慎用正则“切出” JSON 字符串
仅限原始数据非纯 JSON，且你只关心外围定位：比如从 HTML 片段、日志行、JSONP 响应中粗略提取疑似 JSON 的子串，之后必须交给 json_decode() 验证。
- 剥离 JSONP 包裹：
preg_replace('/^\w+\((.*)\);?$/s', '$1', $raw)，再对结果调用json_decode() - 从 script 标签提取变量赋值：
preg_match('/var\s+data\s*=\s*(\{.*?\});/s', $html, $m)，然后json_decode($m[1]) - 日志中固定格式字段提取（如
"status":"ok","code":200）——这本质是字符串采样，不是 JSON 解析
json_decode 才是唯一正确入口
所有合法 JSON 必须走 json_decode()，它处理转义、编码、嵌套、类型映射等全部细节。用正则绕过等于放弃结构保障。
立即学习“PHP免费学习笔记（深入）”；
- 检查错误必须用
json_last_error()或JSON_THROW_ON_ERROR，不能靠正则匹配成功与否判断 - 深度超限（
JSON_ERROR_DEPTH）或 UTF-8 损坏（JSON_ERROR_UTF8）等错误，正则完全无法捕获 - 即使字符串看起来“简单”，只要含中文、换行、反斜杠，就已超出正则安全边界
真正容易被忽略的是：很多人在调试时用正则“确认某字段存在”，却忘了后续仍要 json_decode() —— 这一步若跳过，等于把解析责任甩给不可控的字符串操作。
