json_encode()是php中将数组转为json字符串的唯一标准方法，需确保输入为utf-8编码、无资源/循环引用，并配合错误处理与类型校验。
json_encode() 是唯一可靠的选择
PHP 里把数组转成 JSON 字符串，json_encode() 是标准且唯一推荐的方式。别试 serialize() 或字符串拼接——前者生成的是 PHP 特有格式，后者极易出错且不兼容 Unicode。
常见错误现象：json_encode() 返回 false 却没检查，结果存进数据库或返回前端的是一串空值，调试时才发现原始数组里混了中文但没设 UTF-8 编码。
- 确保输入数组的键和值都是 UTF-8 编码（尤其是从 MySQL 查询出来时，连接要设
charset=utf8mb4） - 遇到
false，立刻用json_last_error()和json_last_error_msg()查原因，比如JSON_ERROR_UTF8就说明有非法字节 - 如果数组含资源（如
mysqli对象）、闭包或循环引用，json_encode()会静默失败，得先用unset()或array_filter()清理
中文乱码？不是函数问题，是编码没对齐
json_encode() 本身不改编码，它只按输入字符串的字节原样处理。所谓“中文变 null”或“显示成 \uXXXX”，根本原因是源数据不是合法 UTF-8。
使用场景：从旧系统读取 GBK 编码的字段，直接丢给 json_encode()，结果中文全变成 null。
立即学习“PHP免费学习笔记（深入）”；
- 用
mb_convert_encoding($str, 'UTF-8', 'GBK')转换后再 encode - 检查
mb_internal_encoding()是否为UTF-8（虽然不影响json_encode()，但能减少其他环节干扰） - 加
JSON_UNESCAPED_UNICODE参数避免中文被转义：json_encode($arr, JSON_UNESCAPED_UNICODE)
关联数组 vs 索引数组：输出结构由键决定
PHP 不区分“对象”和“数组”类型，json_encode() 输出是对象还是数组，完全取决于键名是否为连续数字索引。
参数差异直接影响前端解析逻辑：前端 JSON.parse() 得到的是 Object 还是 Array，会影响你写 data.map 还是 Object.keys(data)。
- 关联数组（含非数字键或不连续数字键）→ 输出 JSON 对象：
['name' => '张三', 'age' => 25]→{"name":"张三","age":25} - 纯索引数组（键为 0,1,2…）→ 输出 JSON 数组：
[1,2,3]→[1,2,3] - 想强制输出数组，即使键名是字符串，可用
array_values($arr)重置键；想强制对象，可加(object)$arr类型转换（但注意会丢掉数字键名）
生产环境必须加错误处理和类型校验
线上代码里直接写 json_encode($data) 是高危操作。一旦 $data 是 null、资源、不可序列化对象，返回 false，后续如果没判断就直接 echo 或入库，轻则接口返回空白，重则触发 PHP Notice 或破坏 JSON 格式。
性能影响很小，但兼容性要注意：PHP 5.5+ 支持 JSON_INVALID_UTF8_IGNORE，但老版本只能靠 mb_check_encoding() 预检。
- 永远用
if (false === $json = json_encode($data)) { /* 记日志 + fallback */ } - 对关键字段做类型断言：
is_array($data) && !empty($data)，避免传入stdClass实例却期望是数组 - 敏感服务建议加
JSON_THROW_ON_ERROR（PHP 7.3+），让异常更明确，而不是靠false判断
最常被忽略的其实是数据源头——不是 json_encode() 不够好，而是你传给它的那个变量，早就在前几步被污染了。查 json_last_error_msg() 前，先 var_dump(gettype($data), $data) 看清楚它到底是什么。
