json_encode返回null主因是输入类型不合规：非UTF-8字符串、资源句柄、循环引用、不可序列化对象或非法键名，需用json_last_error()定位错误并预处理数据。
json_encode 为什么返回 null？
不是数据本身有问题，而是 json_encode 对输入类型非常敏感：它只接受 UTF-8 编码的字符串、数字、布尔、null、数组（索引或关联）、对象（且属性可访问）。一旦遇到资源、闭包、不可序列化的对象（如 mysqli 实例）、含非法字符（如 GBK 中的中文）的字符串，就静默返回 null。
- 检查返回值是否为
null，再用json_last_error()和json_last_error_msg()定位原因 - 中文乱码常见于非 UTF-8 字符串，用
mb_convert_encoding($str, 'UTF-8', 'GBK')转换后再编码 - 含资源或私有/受保护属性的对象，需实现
JsonSerializable接口，或先用get_object_vars()提取公开属性 - 避免直接传入未过滤的 $_POST 或数据库原始结果——它们可能含二进制字段或 null 字节
json_decode 返回 null 或数组/对象不按预期？
json_decode 默认返回 stdClass 对象，但多数人实际需要数组；更关键的是，只要 JSON 字符串语法错误（哪怕一个逗号多写、引号不配对）、编码不对（BOM 头、UTF-8 不合法字节），它就返回 null，不报错也不提示。
- 始终用第二个参数
true：即json_decode($json, true)，强制返回关联数组，避免后续写$obj->key却得到NULL - 用
trim($json)去掉首尾空白，特别是从文件或 curl 响应读取时易带 BOM 或换行 - 检查原始 JSON 是否含单引号（PHP 允许，JSON 标准只认双引号）、注释（JSON 不支持）、尾随逗号（PHP 7.4+ 的 json_decode 仍不支持）
- 从数据库读取 JSON 字段后，别忘了
stripslashes()—— 某些旧版 MySQL 驱动会自动转义反斜杠
处理大 JSON 数据时内存和性能怎么控？
json_encode 和 json_decode 是全量加载的：整个结构必须一次性载入内存。10MB 的 JSON 文件可能撑爆 50MB 内存（PHP 数组开销更大），且解析耗时线性增长。
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
- 用
json_last_error()替代 try/catch ——json_decode不抛异常，捕获不到错误 - 对超大 JSON（如日志导出、批量导入），改用流式解析库如
ext-jsond（需编译安装）或json-machine（基于迭代器，只读当前节点） - 避免在循环里反复
json_encode同一数组——提前 encode 一次，缓存结果 - 注意
max_input_vars和memory_limit配置，大 JSON 解析失败常是这两个值卡住，而非语法问题
PHP 8.2+ 的 JSON 扩展变化要留意
PHP 8.2 开始，json_decode 对无效浮点数（如 "NaN"、"Infinity"）默认拒绝解析（之前静默转为 0），且 json_encode 默认不再允许资源类型（即使你没传，某些对象内部引用也可能触发）。
- 升级前用
json_encode($data, JSON_PARTIAL_OUTPUT_ON_ERROR)容错，让非法值转成null而非中断 - 若需兼容旧行为，加
JSON_INVALID_UTF8_IGNORE或JSON_INVALID_UTF8_SUBSTITUTE处理编码问题 - PHP 8.3 引入
JSON_THROW_ON_ERROR标志，可让json_decode抛出JsonException，但要注意已有错误处理逻辑是否冲突
实际项目里，最常踩的坑不是不会用函数，而是把 json_decode 当万能转换器，忽略了它对输入纯净度的苛刻要求——尤其当数据来自第三方接口、旧系统导出或用户上传时，预处理比硬解更重要。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
