为什么PHP 8.5.5的JSON解析出错【数据】-php教程-PHP中文网

PHP 8.5.5 的 json_decode 出错并非版本问题，根源在于数据本身或调用方式：需立即调用 json_last_error() 查错，注意空字符串、BOM、UTF-8非法字节、读取截断等常见原因。

为什么php 8.5.5的json解析出错【数据】

PHP 8.5.5 的 json_decode 出错，不是版本问题——这个版本本身对 JSON 解析没有引入破坏性变更，出错根源仍在数据本身或调用方式上。

PHP 不会自动抛异常，json_decode() 失败只返回 null，你得主动问它为什么失败。

必须在 json_decode() 后**立刻**调用 json_last_error()，中间不能夹任何其他 JSON 操作（包括 json_encode()、甚至某些扩展的内部调用）
JSON_ERROR_NONE 并不等于“成功”：输入是空字符串、纯空白、或 "null" 字符串时，也返回 null 且错误码为 JSON_ERROR_NONE，所以要先 trim($json) + strlen() 校验
常见真实原因：JSON_ERROR_SYNTAX 往往不是括号漏了，而是 BOM 头、\u0000 控制字符、或中文全角标点混入；JSON_ERROR_UTF8 表示字节流非法，不是简单转码就能救，得先用 mb_convert_encoding($s, 'UTF-8', 'UTF-8') 清洗一遍

远程 API 或本地文件读取后看似是完整 JSON，实际可能被 silently 截断，尤其当内容含二进制或特殊控制符时。

Expanso json-flatten

通过 CLI 或 MCP 服务器，使用 Expanso Edge 管道扁平化嵌套 JSON 对象。

下载

用 var_dump(strlen($json)) 和原始文件大小对比，确认是否读全
如果来源是 cURL，检查是否漏设 CURLOPT_RETURNTRANSFER => true，否则 curl_exec() 返回 bool(true) 而非字符串
若文件含 BOM（如 UTF-8 with BOM），file_get_contents 会原样读入，导致开头三个字节 \xEF\xBB\xBF 破坏 JSON 结构，可用 ltrim($json, "\xEF\xBB\xBF") 剥离

不是解析失败，是根本没走到 json_decode——你把函数名写成了变量。

错误写法：file_put_contents('x.json', $json_encode($data)); → PHP 报 Fatal error: Uncaught Error: Call to a member function ... on null，因为 $json_encode 未定义，默认是 null
正确写法：file_put_contents('x.json', json_encode($data, JSON_UNESCAPED_UNICODE | JSON_PRETTY_PRINT));
别依赖 IDE 自动补全：有些编辑器对 json_* 函数补全不敏感，手敲时多看一眼有没有 $

真正麻烦的从来不是函数怎么用，而是你拿到的那串“看起来像 JSON”的字符串，到底是不是合法 UTF-8、有没有隐藏控制符、是否被中间层（比如 nginx proxy_buffers、cURL timeout、MySQL TEXT 字段截断）悄悄动过手脚——这些地方不排查，光调参数没用。