json_encode 和 json_decode 的难点在于静默失败，根源是编码不一致、非法类型输入、JSON 格式错误及错误处理缺失；需用 mb_convert_encoding、json_last_error_msg()、JSON_THROW_ON_ERROR 等精准定位问题。
json_encode 和 json_decode 不是“学不会”的函数，而是**用错就静默失败、查不出原因**的典型。PHP 自 5.2 起内置支持，但真正卡住人的从来不是语法，是编码、类型、错误处理这三关。
为什么 json_encode 返回 null 或空字符串？
它不报错，只返回 false 或 null，但原因很具体：
- 输入含非 UTF-8 字符串（比如 GBK 编码的中文）→ 先用
mb_convert_encoding($str, 'UTF-8', 'auto') - 传了资源句柄（如
mysqli实例）、闭包、或私有属性未公开的对象 → 改用get_object_vars()提取，或实现JsonSerializable接口 - 数组键名非法（如数字开头的字符串
"123abc"）→ JSON 标准允许，但某些旧版 PHP 解析器会退化为索引数组，导致结构丢失 - 含
\0字节或控制字符 → 用preg_replace('/[\x00-\x08\x0B\x0C\x0E-\x1F\x7F]/', '', $str)清理
为什么 json_decode 返回 null，却没提示哪里错了？
它对输入极其苛刻，且默认不抛异常：
- JSON 字符串带 BOM 头（常见于 Windows 编辑器保存的文件）→ 用
trim($json, "\xEF\xBB\xBF")去掉 - 前端传来的 JSON 用了单引号或尾随逗号 → JSON 标准只认双引号和无逗号，需前端修正或服务端预处理
- 从 MySQL
JSON字段读出后被自动转义 → 加stripslashes() - 没检查返回值就直接访问 → 必须写：
$data = json_decode($input, true); if (null === $data) { die(json_last_error_msg()); }
关联数组还是对象？别靠猜，要明确选
json_decode($json, true) 返回关联数组，json_decode($json) 返回 stdClass 对象。区别不止是写法：
- 数组支持
isset($arr['key'])、array_key_exists()、foreach直接遍历；对象访问$obj->key在 key 含短横线、数字前缀或空格时会报错 - 如果 JSON 顶层是数组（如
[{"id":1},{"id":2}]），json_decode(..., true)得到的是索引数组；不加true得到的是对象数组，foreach仍可用，但count($obj)返回 0 —— 这是新手最常踩的坑 - PHP 7.3+ 可用
JSON_THROW_ON_ERROR：写成json_decode($json, true, 512, JSON_THROW_ON_ERROR)，出错直接抛JsonException，比查json_last_error()更干净
大 JSON 或深层嵌套时内存和结构容易崩
全量加载是硬伤，1MB 的 JSON 字符串可能占 5MB+ 内存，且解析失败往往只报 JSON_ERROR_DEPTH：
立即学习“PHP免费学习笔记（深入）”；
- 默认递归深度是 512，但若 JSON 有 600 层嵌套（恶意构造或日志导出误用），必须显式传
$depth参数，如json_decode($json, true, 1024) - 超大 JSON（如 >5MB）建议改用流式解析器，如
json-machine库，它基于Iterator，只加载当前节点，内存占用恒定 - 避免在循环里反复调用
json_encode同一数据 → 提前 encode 一次，缓存结果 - 注意
memory_limit和max_input_vars配置，尤其是接收 POST 大 JSON 时，后者限制的是变量个数，不是字节数
json_decode($json, true)，而是当它返回 null 时，你能不能在 30 秒内定位是 BOM、编码、还是前端多写了个逗号。这些细节不写进日志、不加断点、不看 json_last_error_msg()，就永远在“明明格式是对的”里打转。 
