thinkphp 6 应使用 return json($data, $code, $header) 标准写法，避免手动 echo json_encode()；tp5.1 中文乱码需确保数据源 utf-8 统一；json_encode() 返回 null 需检查不可序列化内容；json 截断多因缓冲或代理层导致。
ThinkPHP 6 怎么正确返回 JSON 数据
直接用 json() 方法，别手写 header() 或 echo json_encode() —— 框架已封装好，手动处理反而破坏响应生命周期，容易漏掉 Content-Type、状态码或中间件拦截。
常见错误是控制器里写：echo json_encode(['code'=>0]); exit;，结果 CORS 失败、调试工具看不到响应头、日志里没记录、甚至被 gzip 中间件二次压缩出错。
-
return json(['code' => 0, 'data' => $list]);是标准写法，自动设Content-Type: application/json和200状态码 - 需要自定义状态码？传第二个参数：
return json(['msg'=>'未登录'], 401); - 要加额外 header（比如缓存控制）？用第三个参数：
return json($data, 200, ['Cache-Control' => 'no-cache']); - 别在
__construct()或初始化方法里提前输出，ThinkPHP 的响应是单例延迟发送，提前echo会触发 headers already sent 错误
ThinkPHP 5.1 返回 JSON 时中文变空或乱码
本质是 json_encode() 默认不支持 UTF-8 以外编码，而 TP5.1 默认未强制 UTF-8 输入，尤其从数据库或文件读取时可能混入 GBK 字符。
不是加 mb_convert_encoding() 就完事——那只是掩盖问题。真正要做的，是确保数据源头和传输链路统一 UTF-8。
立即学习“PHP免费学习笔记（深入）”；
- 检查数据库连接配置是否含
'charset' => 'utf8mb4'（TP5.1 的database.php） - 确认模型查询返回的字符串确实是 UTF-8：可临时加
var_dump(mb_detect_encoding($str));验证 - 如果必须兼容非 UTF-8 输入，用
json_encode($data, JSON_UNESCAPED_UNICODE | JSON_INVALID_UTF8_SUBSTITUTE)，但这是兜底，不是常态方案 - TP5.1 的
json()不接受编码参数，所以别试图传第四个参数，会报错
原生 PHP json_encode() 返回 null 的排查顺序
返回 null 不代表语法错，大概率是数据里有不可序列化的东西，比如资源句柄、闭包、循环引用对象，或者数组键名含非法字符（如 null、浮点数、负数字符串）。
别急着改代码，先定位哪一层出的问题。
- 用
json_last_error()和json_last_error_msg()查具体原因，例如JSON_ERROR_RECURSION就说明对象里有自己引用自己 - 对变量做
var_dump(gettype($data), is_array($data), is_object($data));，排除资源类型（如mysqli_result）直接传进去 - 数组键名如果是
"1.5"或"-2"，json_encode()会静默失败，需先用array_values()或重键 - 对象要可序列化，得确保没把
private属性里塞了 Closure 或 resource，或者加JsonSerializable接口实现
前后端联调时 JSON 响应被截断或格式错乱
多数情况不是 PHP 问题，而是 Nginx/Apache 输出缓冲、PHP 输出缓冲（output_buffering）、或代理层（如 CDN、WAF）做了截断或重写。
先排除服务端逻辑，再查基础设施。
- 用
curl -i http://your-api直连 PHP-FPM，看原始响应头和 body 是否完整；如果正常，问题在 Web 服务器层 - 检查 PHP 配置：
output_buffering = Off或设为4096以上，避免小响应被缓冲卡住 - Nginx 里确认没配
fastcgi_buffer_size过小，或proxy_buffering on导致大 JSON 被切片 - 某些 WAF（如 Cloudflare）会对
application/json做内容扫描，若检测到疑似 SQL 片段（哪怕只是字段名含user_id）可能静默过滤，换响应类型或联系厂商放行
