thinkphp 的 request 对象不自动转换 gbk/gb2312 编码，必须在 appservice::boot() 中拦截 php://input 和 query_string 并用 mb_convert_variables 原地转码，早于框架解析，确保 input() 和 param() 获取正确 utf-8 数据。
ThinkPHP 的 Request 对象本身不自动检测并转换 GBK/GB2312 等非 UTF-8 编码的请求参数，一旦原始字节被错误解析（比如把 GBK 的“张”当 UTF-8 读），后续所有 $request->param()、input() 返回值都已损坏，无法修复。必须在框架解析前拦截原始输入流。
必须在 AppService 中处理 php://input 和 QUERY_STRING
TP6 构造 Request 实例时，会立即读取并固化 php://input 和 $_GET，你无法靠中间件“后置修复”。唯一可靠位置是应用启动早期——app\common\boot\AppService.php 的 boot() 方法。
- 只对
application/x-www-form-urlencoded和multipart/form-data类型做表单转码；JSON 请求需单独解析php://input后再json_decode - 别依赖
$_SERVER['HTTP_ACCEPT_CHARSET']，它常为空或不可信；建议前端加自定义 header，如X-Input-Charset: GBK - 用
mb_convert_encoding($raw, 'UTF-8', 'GBK')转原始数据，而非iconv('GBK', 'UTF-8//IGNORE', $raw)——后者会静默丢字 - 转完后用
parse_str()解析为数组，再$_POST = array_merge($_POST, $parsed)注入，确保input('post.')可用
不要在中间件里调用 $request->post() 后再试图 merge
$request->post() 是只读缓存，首次调用即固化。你在中间件里执行 $request->merge($data)，对 post() 完全无效，但 param() 和 input() 会生效。这会导致控制器内两个方法返回不一致的结果。
- 统一改用
$request->param()获取所有参数（含 GET + POST + PUT body） - TP6.0.13+ 可调用
$request->setPost($cleaned)同步更新 post 缓存，低版本无此方法，别硬试 - 若必须兼容旧代码，确保中间件注册顺序在
think\middleware\LoadLangPack之后，否则$request->controller()等方法返回空
批量转码数组用 mb_convert_variables 而非递归 mb_convert_encoding
对 $_POST、$_GET 或 input('post.') 返回的数组，直接传给 mb_convert_encoding() 会报错或返回空——它只接受字符串。手动递归又容易漏掉 null、false、数字键等边界情况。
- 用
mb_convert_variables('UTF-8', 'GBK', $_POST, $_GET)，它原地修改变量，跳过非字符串类型，不报错 - 对模型层数据（如
$data = input('post.')），同样可传引用：mb_convert_variables('UTF-8', 'GBK', $data) - 该函数不处理对象实例（如 Eloquent 模型），也不支持自动探测源编码，所以务必明确指定
'GBK'或'GB2312'，别写'auto'
真正难的不是写几行转码代码，而是确保它在框架读取原始输入的**毫秒级窗口内**被执行——早了拿不到 php://input，晚了数据已损坏。AppService 是目前唯一可控且升级安全的位置。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
