ThinkPHP 6 默认自动 URL 解码 $_GET 参数，$request->get('name') 或 input('name') 返回的是已解码值，无需也不应手动 urldecode()，否则会导致二次解码乱码；原始未解码值需从 $_SERVER['QUERY_STRING'] 中解析。
ThinkPHP 6 默认会自动 URL 解码 $_GET 参数
TP6 启动时通过 think\Request 类对原始 $_GET 做了一层封装，默认已调用 urldecode()，所以你拿到的 $request->get('name') 或 input('name') 通常是解码后的中文或特殊字符。不需要手动再 urldecode()，否则可能造成二次解码（比如把 %E4%BD%A0 变成乱码）。
常见错误现象：
• 手动对 input('q') 再套一层 urldecode()，结果中文变问号或
• 在 Nginx + PHP-FPM 环境下，请求中带 %2B（+ 号），手动解码后变成空格，而原生 $_GET 里它就是 +，TP6 封装后默认把它转为空格——这是符合 CGI 规范的，但业务若依赖原始 +，就得换方式取值
- 优先用
$request->param('key')（兼容 GET/POST/Route）而非直接读$_GET - 如需原始未解码值，可从
$_SERVER['QUERY_STRING']中自行解析，或用parse_str(rawurldecode($_SERVER['QUERY_STRING']), $raw) - 注意：TP6 的
input()和param()都走过滤逻辑，若开启default_filter（如htmlspecialchars），会进一步转义，需确认配置项app.default_filter
ThinkPHP 5.1 的 input() 不自动解码，但 I() 会
TP5.1 是个分水岭：原生 input('name') 直接返回 $_GET['name'] 值，没做 urldecode()；而旧版助手函数 I('get.name') 内部调用了 urldecode()。这容易导致同一参数在不同写法下行为不一致。
使用场景：
• 你维护一个 TP5.1 项目，接口被其他系统用 encodeURIComponent 编码传参，用 input('q') 拿到的是 %E4%BD%A0%E5%A5%BD，不是“你好”
• 但用 I('get.q') 就能直接拿到解码后内容
立即学习“PHP免费学习笔记（深入）”；
- 统一用
I('get.key')或input('key', '', 'urldecode')显式解码 - 避免混用
$_GET['key']和input()，因为前者是原始值，后者默认不过滤也不解码 - TP5.1 中
input('key', '', 'htmlspecialchars')的第三个参数是过滤函数，支持传字符串或回调，'urldecode'是合法值
URL 中的 +、空格、斜杠等特殊字符处理差异
浏览器地址栏中空格常被编码为 +，但标准 URL 编码应为 %20；而 /、?、= 这类字符若未被编码，会导致路由或参数截断。TP 对这些的容忍度取决于 Web 服务器和 PHP 配置，不是框架能完全兜底的。
常见错误现象：
• 请求 /search?q=a+b+c，TP 认为 q = "a b c"（+ 被当空格）
• 请求 /search?q=a%2Bb%2Bc，TP 正确识别为 q = "a+b+c"
• 请求 /user/123/name/张三，若 name 值含 / 且未编码，路由匹配失败
- 前端必须用
encodeURIComponent()编码每个参数值，不要拼接 raw URL - 后端不要依赖框架“自动修复”，比如把
+当空格是 CGI 协议行为，非 TP 特性 - 若必须接收含
/的参数，改用 POST 或 base64 编码传参，避免路由层解析失败
调试时怎么看实际收到的原始 GET 数据
别只信 var_dump(input('q'))，它已经过框架封装。要看最原始输入，得绕过 Request 实例：
var_dump($_GET); // 原始 PHP 解析结果（已 urldecode，但受 php.ini 中 arg_separator.input 影响） var_dump($_SERVER['QUERY_STRING']); // 完整未解析字符串，含所有原始 % 编码 var_dump(urldecode($_SERVER['QUERY_STRING'])); // 模拟 TP6 行为
尤其在 Nginx 配置了 merge_slashes off 或使用了自定义重写规则时，$_SERVER['QUERY_STRING'] 可能被意外截断或污染，这时候框架层看到的参数就不可靠了。
真正复杂的地方不在框架怎么解码，而在前端发什么、Web 服务器怎么转发、PHP 怎么解析这三层之间是否对齐。一个 + 字符，可能在 Chrome 地址栏里显示正常，到 Nginx access_log 里变成空格，再到 PHP $_GET 里消失，最后在 TP 里根本收不到——这种链路问题，光看框架文档解决不了。
