json_decode() 返回 NULL 最常见原因是 bom 头或编码问题，而非语法错误；需用 trim 或 mb_convert_encoding 清洗，配合 json_last_error() 调试；第二参数决定返回数组或对象；深层嵌套需手动二次解析；php 7.4+ 需注意 json_throw_on_error 必须配 try/catch。
json_decode() 为什么返回 null
最常见的问题不是 JSON 格式写错了，而是编码或 BOM 头导致 json_decode() 静默失败。PHP 对 UTF-8 的 BOM（xEFxBBxBF）极其敏感，哪怕 JSON 字符串开头多了一个不可见字节，json_decode() 就直接返回 null，且 json_last_error() 可能是 JSON_ERROR_SYNTAX 或更隐蔽的 JSON_ERROR_UTF8。
- 用
file_get_contents()读取文件后，先用trim($json, "x00..x1Fx7F")或mb_convert_encoding($json, 'UTF-8', 'UTF-8')清洗 - 检查原始数据是否含中文但用了 GBK 编码：用
mb_detect_encoding($json)确认，必要时转码mb_convert_encoding($json, 'UTF-8', 'GBK') - 调试时务必加判断：
if (json_last_error() !== JSON_ERROR_NONE) { echo 'JSON error: ' . json_last_error_msg(); }
关联数组还是对象？第二个参数到底怎么选
json_decode() 的第二个参数决定解析结果结构，不是“习惯问题”，而是直接影响后续代码健壮性。
- 传
true→ 返回Array：适合用$data['name']访问，兼容性好，可直接用foreach遍历，但丢失原始键名顺序（PHP 7.4+ 关联数组保持插入顺序） - 传
false（默认）→ 返回stdClass对象：必须用$data->name，不能用isset($data['name'])，且对象属性不存在时会触发 Notice（可用property_exists()判断） - 如果 JSON 里有重复 key（如多个
"id"），对象模式只保留最后一个；数组模式则按顺序存为数值索引，原始 key 信息丢失
深层嵌套 JSON 解析失败怎么办
不是 json_decode() 不行，而是你没意识到它默认只处理一层字符串。当 JSON 字段值本身是 JSON 字符串（比如数据库存的 "{"status":"ok"}"），需要手动二次解析。
- 先用
json_decode($raw, true)得到数组，再对疑似 JSON 的字段（如$data['payload']）单独调用json_decode($data['payload'], true) - 避免递归解析所有字段：检查字段内容是否以
{或[开头，再决定是否解析，否则可能误伤正常字符串 - 性能敏感场景慎用递归：每层
json_decode()都要重新扫描字符串，嵌套深 + 数据量大时明显变慢
PHP 7.4+ 中 json_decode() 的新行为要注意
PHP 7.4 引入了 JSON_THROW_ON_ERROR 标志，但它不是“更好用”，而是改变了错误处理路径——不配合 try/catch 就会直接报致命错误。
立即学习“PHP免费学习笔记（深入）”；
- 旧写法
json_decode($json, true)+ 手动查json_last_error()依然安全、可控 - 新写法
json_decode($json, true, 512, JSON_THROW_ON_ERROR)必须包裹在try/catch中，否则脚本中断，无法 fallback -
JSON_INVALID_UTF8_IGNORE和JSON_INVALID_UTF8_SUBSTITUTE可跳过非法 UTF-8 字节，但会静默丢数据，线上环境慎用
实际项目里最常被忽略的是：JSON 字符串来源不可信（比如用户 POST、第三方 API 返回），json_decode() 前不做长度限制和内容预检，容易引发内存溢出或 DoS 攻击。特别是 max_depth 参数设得过大，又遇到恶意构造的超深嵌套，PHP 进程就卡死了。