json_decode() 必须加 true 参数才得关联数组；返回 null 是设计行为，需用 json_last_error() 查错：语法错、UTF-8 BOM/编码混杂、嵌套超深（默认512层）；json_validate() 仅快筛格式，不转换结构，预检可用，解码前勿重复校验；文件导入须注意路径、UTF-8无BOM、字段名严格匹配及语义映射。
直接用 json_decode() 就行，但必须加 true 参数才能得到可遍历的关联数组；json_validate() 不是导入工具，它只做格式快筛，别指望它帮你转数据结构。
为什么 json_decode() 返回 null 却不报错
这不是 bug，是设计行为——只要 JSON 字符串有语法、编码或深度问题，json_decode() 就静默返回 null，你得主动查错误：
-
json_last_error()返回JSON_ERROR_SYNTAX：常见于前端没用JSON.stringify()、手动拼接时多逗号/单引号/换行未转义 -
JSON_ERROR_UTF8：最常被忽略，源字符串带 UTF-8 BOM（\xEF\xBB\xBF）或混入 GBK 字节，用trim($json, "\xEF\xBB\xBF")或mb_convert_encoding($json, 'UTF-8', 'auto')清理 -
JSON_ERROR_DEPTH：嵌套超限，默认 512 层，大模型响应里messages嵌套 20+ 层很常见，要显式传第三个参数如json_decode($json, true, 1024)
json_validate() 该在哪儿用、不该在哪儿用
json_validate() 是个“守门员”，不是“搬运工”。它只确认括号配对、引号闭合、深度合规，不解析也不转换类型：
- 适合场景：API 请求体预检（
Content-Type: application/json但不立刻解码）、日志字符串批量清洗、存入 raw_log 表前轻量过滤 - 不适合场景：紧接着就要
json_decode()——重复校验浪费 CPU，直接用json_decode($input, flags: JSON_THROW_ON_ERROR)更高效 - 关键陷阱：
$depth和$flags必须和后续json_decode()保持一致；比如你校验时用默认512，但解码时传了1024，那校验通过的字符串可能在解码时失败
从文件读 JSON 导入班级通信录的实操要点
路径、编码、字段映射这三步错一个，整个导入就失效：
- 路径别写相对路径如
"data/contacts.json"，用__DIR__ . '/data/contacts.json'，否则脚本在 CLI 和 Web 下行为不一致 - 文件必须是 UTF-8 无 BOM，编辑器保存时留意选项；读取后先
trim()去首尾空白，再json_validate()过一遍，避免file_get_contents()拉进来不可见字符 - 字段名必须严格匹配：JSON 里是
"student_id"，PHP 就不能按$item['stu_id']取值；建议导入前加校验：isset($item['name']) && isset($item['student_id']) - 手机号、学号这类字段别自动转 int——
"0023"会被截成23，一律当字符串处理
真正容易被忽略的是字段语义映射：JSON 中的 "class" 字段，数据库表里叫 grade，这种关系必须硬编码声明，不能靠命名猜测。一旦 JSON 结构变更（比如把 "phone" 改成 "mobile"），不改 PHP 侧字段提取逻辑，数据就全丢了。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
