thinkphp 6 的 input() 不自动处理 url 编码和字符集转换，需在全局中间件或 initialize() 中用 mb_convert_encoding() + urldecode() 统一解码；json 请求须确保 content-type 含 charset=utf-8 并手动解析 php://input；param() 与 input() 编码行为完全一致；apache 配置无效，应聚焦 php 层原始输入归一化。
ThinkPHP 6 的 input() 默认不处理编码，得自己转
ThinkPHP 6 的 input() 函数直接取 $_GET / $_POST 原始值，不会自动做 urldecode() 或字符集转换。如果前端传的是 UTF-8 编码的中文 URL 参数（比如 ?name=%E4%BD%A0%E5%A5%BD），input('name') 拿到的就是已解码的字符串；但如果某些客户端或网关二次编码（如 %25E4%25BD%25A0），就会变成乱码或问号。
常见错误现象：input('title') 返回 "???" 或空字符串，但 $_GET['title'] 看起来是正常百分号编码；或者 POST 表单提交含中文字段后，input('content') 变成乱码。
- 必须在全局中间件或 Base Controller 的
initialize()中统一处理，不能只在某个接口里临时urldecode() - 优先用
mb_convert_encoding()+urldecode()组合，别依赖iconv()（PHP 8.2+ 已废弃） - 注意：
input()对数组参数（如input('list/a')）会递归处理，但自定义解码逻辑需手动遍历，否则深层键值仍可能乱码
POST 请求中 JSON Body 的中文乱码不是编码问题，是 Content-Type 没配对
当用 fetch 或 axios 发送 Content-Type: application/json 请求时，ThinkPHP 默认不解析 JSON body，input() 拿不到任何值——除非你显式调用 input('', '', false) 并手动 json_decode(file_get_contents('php://input'), true)。这时候如果 JSON 字符串本身是 UTF-8，但请求头漏了 ; charset=utf-8，某些旧版 Nginx 或代理会按 ISO-8859-1 解析原始流，导致中文变乱码。
- 前端必须确保发送 JSON 时带完整 header：
Content-Type: application/json; charset=utf-8 - ThinkPHP 6.1+ 可在
app/middleware.php中注册一个中间件，在$request->getContent()后检查是否为 JSON，再强制以 UTF-8 解析 - 不要在控制器里反复写
json_decode(file_get_contents('php://input'))，容易漏掉trim()和空内容判断，导致null或解析失败
Request::instance()->param() 和 input() 在编码行为上完全一致
有人以为 Request::instance()->param() 是“更底层”的接口，能绕过编码问题，其实它和 input() 共享同一套参数解析逻辑，底层都走 think\Request::filterValue()，默认不做额外转码。区别只在于：param() 合并 GET/POST/ROUTE，input() 默认只读 POST，加 'get.' 前缀才读 GET——但两者对编码的处理毫无差别。
- 不要因为换函数名就以为能解决乱码，重点还是看原始输入流是否被正确解码
- 调试时可直接打印
file_get_contents('php://input')和$_SERVER['QUERY_STRING']，对比原始字节，比猜input()行为更可靠 - 若用了 Swoole 或 RoadRunner，
php://input可能不可读，此时必须依赖 Swoole 的$request->rawContent()并确保其编码正确
Apache + mod_php 下的 .htaccess 不影响 PHP 层编码，别白配
有些人在项目根目录加 AddDefaultCharset UTF-8 或 SetEnvIfNoCase 规则，指望靠 Apache 配置解决 ThinkPHP 接收参数的乱码。这是无效的——Apache 的字符集设置只影响响应头和静态文件输出，对 $_GET/$_POST 的原始字节无任何干预。PHP 解析这些超全局变量时，完全由自身扩展（如 php_url_scanner）决定如何 decode，跟 Apache 无关。
- 真正要配的是 PHP 配置：
default_charset = "UTF-8"（仅影响 header，默认已设）和mbstring.http_input = "UTF-8"（PHP 7.4+ 已移除，勿设） - 如果你用的是 Nginx + PHP-FPM，确认
fastcgi_param没覆盖QUERY_STRING或篡改原始值（某些安全模块会做 URL 过滤） - 最稳的方式：所有外部输入（URL、表单、API）在进入业务逻辑前，统一用
mb_convert_encoding($str, 'UTF-8', 'auto')强制归一化，'auto'能识别 GBK/GB2312/UTF-8，比硬写'GBK'更容错
真正麻烦的不是怎么转码，而是同一个参数在不同入口（URL、Form、JSON、CLI）下，原始编码状态完全不同——有的已被 decode 一次，有的被代理多 encode 一层，有的根本没进 $_POST。所以别信“统一配置就能搞定”，得按入口类型分别验、分别转。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
