json_encode() 默认将中文转为\uXXXX是正常行为，需加JSON_UNESCAPED_UNICODE参数保留原始中文；若返回false，多因输入非合法UTF-8，应检查并统一全链路UTF-8编码。
json_encode() 输出中文变成 \uXXXX 怎么办
这是正常行为，不是乱码。PHP 的 json_encode() 默认对非 ASCII 字符（包括中文）做 Unicode 转义，输出类似 {"name":"\u4f60\u597d"}。浏览器和大多数 JSON 解析器都能正确还原，但如果你需要可读的原始中文，得加参数。
- PHP 5.4+ 支持
JSON_UNESCAPED_UNICODE标志，直接保留中文字符 - PHP 8.4 依然沿用该机制，没有变化
- 错误做法：手动替换
\uXXXX或用urldecode()—— 这会破坏 JSON 结构
echo json_encode(['msg' => '你好'], JSON_UNESCAPED_UNICODE);
// 输出：{"msg":"你好"}
json_encode() 返回 false 且中文字段丢失
这通常不是编码问题，而是输入数据本身含非法字符或编码不一致。PHP 8.4 对 UTF-8 合法性校验更严格，遇到无效 UTF-8 字节序列（比如 GBK 混入、截断的 emoji、BOM 头）会直接返回 false，且不报错（除非开启 json_last_error() 检查）。
- 先确认源数据是合法 UTF-8：
mb_check_encoding($str, 'UTF-8') - 常见污染源：MySQL 查询未设
SET NAMES utf8mb4、文件读取未指定mb_internal_encoding('UTF-8')、表单提交时accept-charset缺失 - 临时修复可用
mb_convert_encoding($str, 'UTF-8', 'UTF-8')强制重编码（会静默修正部分错误）
$data = ['name' => "\xff\xfe\xfd\xfc"]; // 无效 UTF-8 var_dump(json_encode($data)); // bool(false) var_dump(json_last_error_msg()); // "Malformed UTF-8 characters, possibly incorrectly encoded"
PHP 8.4 中 json_encode() 对 emoji 和四字节 UTF-8 的要求
PHP 8.4 默认仍要求 MySQL 使用 utf8mb4、PHP 字符串为合法 UTF-8，且必须启用 JSON_UNESCAPED_UNICODE 才能原样输出 emoji（如 ?）。否则会被转成 \uD83C\uDDE8\uDDF3 形式（代理对），某些旧环境解析可能出错。
- 确保数据库连接已执行
SET NAMES utf8mb4 - 避免用
iconv('GBK', 'UTF-8', $str)粗暴转换，它可能丢字或产生乱码 - 如果必须兼容老系统，可加
JSON_PARTIAL_OUTPUT_ON_ERROR（PHP 7.3+），让非法字符被替换为null而非整个失败
$emoji = ['flag' => '??'];
echo json_encode($emoji, JSON_UNESCAPED_UNICODE | JSON_PARTIAL_OUTPUT_ON_ERROR);
// 输出：{"flag":"\u2705"}（若原始字符损坏）或 {"flag":"??"}（正常）
为什么 header('Content-Type: application/json; charset=utf-8') 还是显示乱码
HTTP 响应头只是声明编码，不能修复内容本身。如果 json_encode() 输出的是乱码字节（比如把 GBK 当 UTF-8 编码），加 header 也没用。重点永远在「输入是否真为 UTF-8」。
立即学习“PHP免费学习笔记（深入）”；
- 检查响应体原始字节：
bin2hex(file_get_contents('php://input'))或用 curl -i 看 raw body - 不要依赖 IDE 或编辑器显示判断——它们可能自动转码渲染
- Chrome 开发者工具 > Network > Response 面板右键 → “Save response as…”，用 hex editor 查看真实字节
最稳妥的做法：所有环节统一 UTF-8，从数据库、PHP 文件保存编码、HTTP 请求头、到 json_encode() 参数，缺一不可。PHP 8.4 不新增编码逻辑，只是更早暴露你之前忽略的问题。
