json_decode 返回 null 的常见原因包括：输入为空或非字符串、含BOM/控制字符、键名超整型范围、编码不兼容；需用json_last_error()定位错误，并验证清洗输入。
json_decode 返回 null 的常见原因
json_decode 返回 null 并不总代表 JSON 格式错误，它只说明解码失败——而失败可能来自多个环节。PHP 不会抛出异常（除非启用 JSON_THROW_ON_ERROR），所以你得主动查错。
- 输入字符串为空、
null或非字符串类型（比如数组）时，直接返回null - 字符串含 BOM 头（尤其 Windows 编辑器保存的 UTF-8 文件）、不可见控制字符（如
\u0000）会导致静默失败 - JSON 中存在 PHP 无法表示的结构，比如键名是纯数字但超出整型范围（
"12345678901234567890"作 key），部分版本会丢弃整个对象 - 使用了不兼容的编码：输入是 GBK 或 UTF-16，但没转成 UTF-8 就传给
json_decode
用 json_last_error() 和 json_last_error_msg() 定位具体错误
别只看返回值，每次调用 json_decode 后立刻检查错误状态：
$json = file_get_contents('data.json');
$data = json_decode($json, true);
if ($data === null && json_last_error() !== JSON_ERROR_NONE) {
echo 'JSON 错误码：' . json_last_error() . "\n";
echo '错误信息：' . json_last_error_msg() . "\n";
}常见错误码含义：
-
JSON_ERROR_SYNTAX：最常见，语法不对（缺引号、逗号、括号不匹配） -
JSON_ERROR_UTF8：字节流不是合法 UTF-8（BOM、混合编码、截断） -
JSON_ERROR_DEPTH：嵌套太深（默认 512 层，可调但少见） -
JSON_ERROR_CTRL_CHAR：遇到 ASCII 控制字符（如\x00–\x1f，常来自二进制混入或剪贴板污染）
验证和清洗输入字符串的实操步骤
在调用 json_decode 前，做这几件事能快速排除大部分问题：
立即学习“PHP免费学习笔记（深入）”；
- 检查输入是否为字符串：
is_string($json)，否则先(string)$json强转（但要警惕对象转字符串可能产生意外内容） - 去除首尾空白：
trim($json)，尤其防止换行或空格导致json_last_error()报JSON_ERROR_SYNTAX - 检测并移除 UTF-8 BOM：
ltrim($json, "\xEF\xBB\xBF") - 替换常见非法控制字符（仅保留可打印 UTF-8）：
preg_replace('/[\x00-\x08\x0B\x0C\x0E-\x1F\x7F]/', '', $json) - 如果来源是 HTTP 接口，确认响应头
Content-Type是application/json，且响应体没被 gzip 二次编码（gzdecode后再解 JSON）
注意 json_decode 的参数陷阱
json_decode($json, $assoc, $depth, $options) 四个参数里，后两个容易被忽略但影响行为：
-
$depth默认 512，如果 JSON 嵌套超限，结果为null且错误码是JSON_ERROR_DEPTH；增大前先确认是否真需要那么深（可能是数据建模问题） -
$options可传JSON_BIGINT_AS_STRING：避免大整数（如微博 ID、Snowflake ID）被转成float导致精度丢失，间接引发后续逻辑判断失败 -
$assoc = true是常用选项，但如果原始 JSON 有重复 key，PHP 会静默覆盖（后者生效），这不是错误，但可能造成数据丢失——这不会让json_decode返回null，却常被误认为“解析失败”
真正难排查的，往往是那些没报错但数据不对的情况：比如字符串里混了不可见字符，json_last_error() 却返回 JSON_ERROR_NONE，因为 PHP 认为它是合法 JSON（例如 "\u0000" 是合法 Unicode 转义）。这时候得靠 bin2hex() 看原始字节，或者用在线 JSON 验证器粘贴原始字符串。
