ThinkPHP 的 input() 不校验路径嵌套合法性，userinfo 等格式会被 PHP 自动解析为数组并透传，导致 input('user.name') 失效；需在全局中间件中正则拦截含[ ] . 的非法键名并限制嵌套深度。
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_recursive - ThinkPHP 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 都已经变形了。
