PHP json_encode()默认转义中文是遵守RFC 8259的保守设计，为确保ASCII安全而将非ASCII字符转为\uXXXX；加JSON_UNESCAPED_UNICODE仅在输入确为UTF-8时才原样输出中文，否则可能返回null。
PHP 的 json_encode() 会转义中文，不是因为出错，而是默认遵守 JSON 标准（RFC 8259）的保守设计：它把所有非 ASCII 字符（包括中文、emoji、全角标点等）自动转换成 \uXXXX 形式的 Unicode 转义序列。
这种行为确保生成的 JSON 字符串在任意编码环境下都“安全可传输”，但代价是牺牲了可读性——你在日志里看到的是 {"name":"\u5f20\u4e09"}，而不是 {"name":"张三"}。
真正的原因有三层：
- 协议层要求：JSON 规范不强制规定传输编码，只保证 ASCII 安全。转义非 ASCII 字符是最稳妥的兼容方案。
-
PHP 实现策略：为避免因输入编码混乱导致
json_encode()返回false或截断，PHP 默认选择“宁可转义，不可报错”。 - 历史兼容性：早期 PHP 版本（<5.4）不支持 UTF-8 原生输出，转义是唯一可靠方式；后续虽新增选项，但默认行为保持不变以维持向后兼容。
所以，中文被转义 ≠ 乱码，也 ≠ bug，而是一种有意为之的编码保守主义。
立即学习“PHP免费学习笔记（深入）”；
为什么加了 JSON_UNESCAPED_UNICODE 就不转义了？
这个常量告诉 PHP：“我确认输入数据已是合法 UTF-8，且整个链路（文件、数据库、HTTP 头）都支持 UTF-8，你不用替我兜底，直接输出原始字节即可。”
但它不会帮你修复编码问题：如果 $data['name'] 实际是 GBK 编码的 "张三"，即使加了该选项，json_encode() 仍可能返回 null 或错误结果。
常见误解澄清
❌ “加了
JSON_UNESCAPED_UNICODE还是乱码，说明选项没起作用”
→ 更可能是数据本身不是 UTF-8（比如从 GBK 数据库查出来没转码）。❌ “前端显示
\u4f60\u597d是后端没设 header”
→\uXXXX是 JSON 字符串内容，和Content-Type无关；header 只影响浏览器如何解码响应体字节流。❌ “用
utf8_encode()万能转换”
→ 它只适用于 ISO-8859-1 源数据；对 GBK、BIG5 等会损坏字符，应优先用mb_convert_encoding($str, 'UTF-8', $detected_encoding)。
怎么判断是否真需要关掉转义？
- ✅ 需要：API 调试、日志查看、第三方系统人工读取 JSON、前端控制台直接 inspect。
- ⚠️ 慎用：嵌入 HTML
<script>的 JSON（旧版 IE 有兼容风险）、需严格遵循某些老旧规范的场景。 - ❌ 不必：纯机器通信（如 curl 请求、微服务间调用），现代解析器自动处理
\uXXXX。
本质上，这是可读性与兼容性的权衡，而非技术缺陷。
