ThinkPHP 的 input() 默认不校验路径嵌套合法性
直接用 input(‘user.info.name’) 拿参数时，ThinkPHP 会自动解析点号路径，但不会拒绝 user[info][name] 这类原始嵌套格式——哪怕你没开 url_param_type 或没配 param_filter，它也可能被 PHP 自动转成数组并透传进来。这不是 bug，是 PHP CGI 模式下 _GET/_POST 的默认行为，但对 ThinkPHP 路由和验证层来说，属于“意外输入”。
常见错误现象：input(‘user.name’) 返回空，但 input(‘user’) 却是个数组；或者验证规则写 [‘user.name’=>’require’] 失效，因为实际结构是 [‘user’=>[‘info’=>[‘name’=>’xxx’]]}。
必须在入口或中间件里统一拦截原始嵌套键名，不能依赖控制器里手动 array_walk_recursiveThinkPHP 6.0+ 的 Request 对象默认已过滤掉 [] 形式键名（如 user[info]），但若通过 CLI、CURL 带 Content-Type: application/x-www-form-urlencoded 提交，仍可能绕过如果项目启用了 app_middleware，建议在全局中间件中处理，避免每个控制器重复判断
用 filter_var + 正则预筛请求键名是否含非法路径字符
不是所有嵌套都该被禁止——比如 RESTful 场景下 filter[status]=active 是合理需求。真正要拦的是带方括号、点号混用、或深度超 2 层的键名，例如 user[profile][settings][theme] 或 data.user.info.name。
实操建议：在 app/middleware/CheckParamPath.php 中写：
立即学习“PHP免费学习笔记（深入）”；
public function handle($request, \Closure $next){ $raw = array_merge($request->get(), $request->post()); foreach ($raw as $key => $val) { // 只检查键名，不递归检查值 if (preg_match(‘/[\[\]\.]/’, $key) || substr_count($key, ‘.’) > 2 || substr_count($key, ‘[‘) > 1) { throw new \think\Exception(‘Invalid parameter path: ‘ . $key, 400); } } return $next($request);}注意：不要用 is_array($val) 判断嵌套，因为 $_POST 已被 PHP 解析，user[info] 在 $_POST 里已经是数组，键名反而变成 user正则 /[\[\]\.]/ 覆盖三种非法符号，比只拦 [] 更稳妥深度限制设为 2 层（如 a.b.c 不允许）是因为 ThinkPHP 的 input() 点号解析本身只支持两级，更深会静默失败
input() 和 param() 在扁平化场景下的行为差异
input() 是原始输入代理，param() 是经路由和变量合并后的“逻辑参数”，二者对点号路径的解析逻辑一致，但来源不同。当存在非法嵌套时，param(‘user.name’) 可能返回 null，而 input(‘user’) 却返回数组——这说明参数已在 PHP 层被提前解析，ThinkPHP 来不及干预。
永远优先用 param() 做业务逻辑取值，它经过了 Request::mergeParam() 合并，更贴近真实业务意图input() 适合做白名单校验或调试，比如 input(”, ”, ‘htmlspecialchars’) 全局过滤，但它不解决路径结构问题如果必须用 input(‘user.info’)，请确保前端提交方式为 application/json 并配合 json_decode($request->getContent(), true) 手动接管，避开 PHP 自动解析
验证器里写 rule 时别依赖嵌套字段名
ThinkPHP 验证器的 rule 数组键名（如 ‘user.name’ => ‘require’）本质是路径表达式，但它只在 validate()->check() 时才解析。一旦原始数据结构是嵌套数组，这个规则就会失效——因为验证器拿到的是整个 user 数组，而不是展开后的 user.name 字段。
正确做法：把嵌套结构先 flatten，再验证。可用 think\helper\ArrayHelper::flatten($data, ‘.’)（TP6.1+ 内置）或者改用数组验证规则：’user’ => [‘require’, [‘info.name’ => ‘require’]]，但这要求你明确知道嵌套层级最稳方案：在验证前强制走一次 input(”, [], ‘array’) + 自定义 flatten 函数，把所有 [ 和 . 都转成点号路径，再喂给验证器
真正麻烦的不是怎么写规则，而是前端发来的 Content-Type 类型和服务器 CGI 模式共同决定的原始解析时机——这点很容易被忽略，等出问题时才发现日志里连原始 $_POST 都已经变形了。
评论(0)