php处理json数据核心是json_encode()和json_decode()；中文乱码需加json_unescaped_unicode，解析后统一用数组避免对象访问错误，必须配合json_last_error()检查错误，bom头和编码不一致需预处理，嵌套访问前须做存在性判断。
PHP处理JSON数据，核心就两件事：json_encode() 和 json_decode()。其他所有问题——中文乱码、解析失败、嵌套访问报错、空值判断异常——基本都源于这两个函数的参数误用或错误忽略。
json_encode() 中文被转成 \u4f60\u597d 怎么办
这是默认行为，不是 bug。PHP 为兼容性把 UTF-8 中文转成 Unicode 转义序列，但接口返回或日志里看着难受。
- 必须加
JSON_UNESCAPED_UNICODE标志：json_encode($data, JSON_UNESCAPED_UNICODE) - 别只加这一个：生产环境避免
JSON_PRETTY_PRINT，它会插入空格和换行，导致签名验签失败或前端JSON.parse()报错 - 如果数据含 HTML 字符（比如用户提交的富文本），
json_encode()不会自动转义或 <code>"；需按需在编码前用htmlspecialchars()处理，否则可能引发 XSS - 资源类型（如
mysqli句柄、文件指针）无法被编码，会静默丢弃对应字段，提前unset()或过滤掉
json_decode() 解析后是对象还是数组
json_decode() 默认返回 stdClass 对象；设为 true 才返回关联数组。混用 -> 和 [] 是新手最常踩的坑。
- 统一用数组：始终传
true，后续所有访问都用$arr['key']，避免Trying to get property 'xxx' of non-object - 对象有其适用场景：比如你明确要复用已有类方法，或想用
property_exists()判断字段是否存在 - 注意空数组和空对象区别：
json_decode('[]', true)返回[]（PHP 空数组），json_decode('{}', true)也返回[]——PHP 里空对象解码后就是空数组，这点容易误判
json_decode() 返回 null 却查不到错误原因
json_decode() 静默返回 null 并不等于失败，只有配合 json_last_error() 才能定位真实问题。
- 必须检查：
if ($result === null && json_last_error() !== JSON_ERROR_NONE)，仅判null会漏掉JSON_ERROR_DEPTH（嵌套太深）等边界情况 - BOM 头是隐形杀手：UTF-8 文件开头的
\xEF\xBB\xBF会让整个字符串解析失败，用trim($json, "\xEF\xBB\xBF")预清洗 - 编码不一致：从
curl或$_POST接收的字符串可能含 GBK/ISO-8859-1，先用mb_convert_encoding($json, 'UTF-8', 'auto')统一再解码 - JSON 语法错常见于拼接字符串生成 JSON 的场景（如手动拼
"{}"），优先用json_encode()生成，而非字符串拼接
嵌套结构取值前不做存在性判断
直接写 $data['package']['items'][0]['name'] 很危险——任意一级缺失都会触发 Notice: Undefined index 或 Trying to access array offset on value of type null。
- 用 null 合并运算符逐层兜底：
$name = $data['package']['items'][0]['name'] ?? 'N/A' - 对不确定是否存在的键，先用
isset()或array_key_exists()判断，尤其在循环中提取字段时 - 从数据库读取 JSON 字段后，别忘了
stripslashes()——某些旧版 MySQL 驱动会自动转义反斜杠 - 处理大 JSON 数据时注意
memory_limit和max_input_vars，解析失败常是这两个值卡住，而非语法问题
最常被忽略的其实是“预处理”环节：BOM 清洗、编码归一、空格截断、file_get_contents() 成败校验——这些动作不在 JSON 函数里，却决定了解析能否真正开始。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
