ThinkPHP JSON中文转义非bug，根本解决需在json()中传JSON_UNESCAPED_UNICODE常量；TP6.1+可全局配置'json_encode'=>[JSON_UNESCAPED_UNICODE|JSON_UNESCAPED_SLASHES]；须同步确保数据库字符集utf8mb4、请求体正确解码、文件UTF-8编码。
ThinkPHP 中 JSON 返回的中文被转成 \u4f60\u597d 这类 Unicode 形式，不是 bug，是 PHP 原生 json_encode() 的默认行为；修复关键在于显式传入 JSON_UNESCAPED_UNICODE，而不是改编码或重装扩展。
json() 助手函数中文被转义怎么办
直接调用 json($data) 时，中文会变成 \uXXXX，因为底层没带 JSON_UNESCAPED_UNICODE 标志。
- 正确写法是：
json($data, JSON_UNESCAPED_UNICODE)—— 注意JSON_UNESCAPED_UNICODE是常量，不是字符串，别加引号 - TP6.1+ 可在
config/app.php里统一配置：'json_encode' => [JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES]，之后所有json()、response()->json()、异常响应都自动生效 - TP5.1 不支持该配置项，只能每个地方手动传参，无法全局覆盖
- 别用
response()->json($data)替代json()来“绕开”问题——它返回的是 Response 对象，会立即结束请求，不适合用于日志、缓存等非响应场景
数据库读写中文乱码连带导致 JSON 转义异常
即使 JSON 编码开了 JSON_UNESCAPED_UNICODE，如果数据库查出来的字段本身就是乱码（比如显示为 “寮笁”），那最终 JSON 里仍是乱码字符串，而非正常中文。
- 检查数据库连接配置：
'charset' => 'utf8mb4'必须写死，不能写utf8或留空 - 确认 MySQL 服务端变量：
character_set_server和collation_server都要是utf8mb4_unicode_ci - TP6 默认不自动执行
SET NAMES utf8mb4，建议在app/common.php中手动触发：Db::connect()->execute('SET NAMES utf8mb4 COLLATE utf8mb4_unicode_ci') - 已有表字段若原为
utf8字符集，需用原生命令升级：ALTER TABLE `users` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci
GBK/GB2312 请求参数导致输入即乱码，JSON 输出跟着错
前端用 GBK 提交表单（如老旧设备或 IE），TP6 默认只按 UTF-8 解析 php://input，原始字节一丢，后面怎么 encode 都救不回来。
立即学习“PHP免费学习笔记（深入）”；
- 必须在框架解析
$_POST/$_GET前介入，不能靠中间件“事后修复” - 推荐在
app\common\boot\AppService.php的boot()方法中处理：用mb_convert_encoding($rawPost, 'UTF-8', 'GBK')转码原始php://input，再parse_str()注入$_POST - 别用
iconv('GBK', 'UTF-8//IGNORE', $str)——//IGNORE会静默丢字，mb_convert_encoding更可控 -
$_SERVER['HTTP_ACCEPT_CHARSET']不可靠，建议前端加自定义 header 如X-Input-Charset: GBK辅助判断
最易被忽略的点：JSON 中文不转义只是表象，根源常在数据源头 —— 数据库连错了字符集、请求体没正确解码、甚至文件本身保存为 ANSI 编码。先确认这三处 UTF-8 链路完整，再调 JSON_UNESCAPED_UNICODE 才真正有效。
