PHP JSON编程入门教程

PHP 的 JSON 处理看似简单，实则暗藏陷阱：`json_encode` 和 `json_decode` 从不轻易报错，却常静默返回 `null` 或 `false`，真正卡住开发者的不是语法，而是 UTF-8 编码不一致、非法数据类型（如资源、闭包）、JSON 格式细微违规（BOM、单引号、尾随逗号）、错误处理缺失等隐蔽问题；掌握 `mb_convert_encoding` 清理编码、`json_last_error_msg()` 快速定位、`JSON_THROW_ON_ERROR` 主动抛异常、合理设置递归深度与流式解析策略，才能告别“明明格式正确却解析失败”的调试噩梦——这是一场关于细节、习惯与工程意识的实战课。

为什么 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：

• 默认递归深度是 512，但若 JSON 有 600 层嵌套（恶意构造或日志导出误用），必须显式传 $depth 参数，如 json_decode($json, true, 1024)
• 超大 JSON（如 >5MB）建议改用流式解析器，如 json-machine 库，它基于 Iterator，只加载当前节点，内存占用恒定
• 避免在循环里反复调用 json_encode 同一数据 → 提前 encode 一次，缓存结果
• 注意 memory_limit 和 max_input_vars 配置，尤其是接收 POST 大 JSON 时，后者限制的是变量个数，不是字节数

今天关于《PHP JSON编程入门教程》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！