ThinkPHP 6 遇 GBK/GB2312 请求时 input() 乱码不可逆，因 Request 构造即强制 UTF-8 解码且不检测原始编码；必须在应用启动早期（如 AppService boot 方法）拦截 php://input 和 QUERY_STRING，按明确线索（如 X-Input-Charset）调用 mb_convert_encoding 手动转码 $_GET/$_POST，禁用 mb_detect_encoding 和源码修改。
ThinkPHP 6 遇到 GBK/GB2312 提交的请求时，input() 返回值直接乱码且不可逆——这不是配置能修好的问题，必须在框架解析原始输入前动手干预。
TP6 中 $_GET 和 $_POST 为什么转码无效
TP6 的 think\Request 在构造时就调用 mb_convert_encoding($rawInput, 'UTF-8', 'UTF-8')，它不检测原始编码，也不 fallback。一旦原始字节被错误解码，$_GET、$_POST 已经损坏，中间件里再调 mb_convert_encoding() 没用。
- 不能靠
input('name')后修复：原始php://input和QUERY_STRING字节流已丢失 - 不能改
Request类源码：升级会覆盖，维护成本高 -
mb_detect_encoding()对 HTTP 请求体基本不可靠：短文本、纯 ASCII、无 BOM 的 GBK 都容易误判为 UTF-8
在 AppService 中拦截原始输入并重写 $_GET/$_POST
最稳妥的方式是在应用启动早期（如 app\common\boot\AppService.php 的 boot() 方法）还原原始数据流，按明确线索判断是否需转码。
- 优先用自定义 header 判断，比如客户端加
X-Input-Charset: GBK，比依赖HTTP_ACCEPT_CHARSET可靠得多 - 只处理
application/x-www-form-urlencoded和multipart/form-data类型；JSON 请求需单独读php://input并转码 - 用
mb_convert_encoding($str, 'UTF-8', 'GBK')，不用iconv('GBK', 'UTF-8//IGNORE', $str)——//IGNORE会静默丢字 - 对
QUERY_STRING要先parse_str()再合并，避免覆盖已有$_GET参数
批量转换 $_GET 和 $_POST 数组的快捷方式
如果确认所有请求都是 GBK 编码，且变量结构简单（不含对象或资源），可用 mb_convert_variables() 一步到位：
立即学习“PHP免费学习笔记（深入）”；
$from = 'GBK'; $to = 'UTF-8'; mb_convert_variables($to, $from, $_GET, $_POST);
- 该函数直接修改原数组，无需重新赋值
- 仅支持标量和数组，遇到对象或资源会跳过且不报错
- 不适用于含文件上传的
$_FILES，也不能修复已损坏的$_SERVER['QUERY_STRING'] - 仍需确保
mbstring扩展已启用，否则函数不存在
为什么不要依赖 Input::setCharsetDetect()（TP5.1）
TP5.1 提供了 Input::setCharsetDetect()，但实际场景中探测极易失效：
- 老旧 IE 或嵌入式设备发来的 GBK 表单，常不带
Accept-Charset头，探测直接退化为默认 UTF-8 - 探测结果只影响
input()，不影响日志记录、数据库写入等环节，编码不一致风险仍在 - 日志中写入乱码后，问题无法回溯；数据库字段若设为
utf8mb4却存了 GBK 字节，后续查不出来
真正要解决的不是“怎么让框架猜对”，而是“怎么让原始输入在进框架前就变成 UTF-8”——线索越明确（如固定 header）、动作越早（启动阶段）、路径越短（绕过 Request 构造），越不容易出岔子。
