Request::param() 返回扁平数组，需手动调用 flattenToNested 函数将 user[name] 等方括号键名还原为嵌套数组，验证器才可正确识别 user.name 等点号路径字段。
Request::param() 不能直接解析 user[name] 这类嵌套键名
ThinkPHP 默认不把 user[name]、profile[contact][email] 这种一维表单键名自动转成嵌套数组。你调用 Request::param('user.name') 会返回 null，因为实际键名是带方括号的字符串，不是点号路径。
这不是 bug，是框架设计：它只做基础参数合并（路由变量 > POST > GET），不介入结构还原。
-
Request::param()返回的是扁平数组，键为user[name]，值为对应字符串 -
Request::post()和$_POST也一样，原样保留方括号键名 - 验证器（如
Validate::check()）若直接传入扁平数组，会因字段路径不匹配而校验失败
必须手动写 flattenToNested 解析逻辑
核心思路是遍历所有键名，按 [ 和 ] 切分路径，逐级构建嵌套结构。推荐封装成独立函数，避免每次重复写。
示例（适用于 TP5.1+ 和 TP6.x）：
立即学习“PHP免费学习笔记（深入）”；
function flattenToNested($data) {
$result = [];
foreach ($data as $key => $value) {
if (false === strpos($key, '[')) {
$result[$key] = $value;
continue;
}
$parts = preg_split('/\[|\]/', $key, -1, PREG_SPLIT_NO_EMPTY);
$ref =& $result;
foreach ($parts as $i => $part) {
if (!isset($ref[$part])) {
$ref[$part] = [];
}
if ($i === count($parts) - 1) {
$ref[$part] = $value;
} else {
$ref =& $ref[$part];
}
}
}
return $result;
}
<p>// 在控制器中使用：
$flat = $this->request->param(); // 得到 ['user[name]' => 'Tom', 'user[age]' => '25']
$nested = flattenToNested($flat); // 得到 ['user' => ['name' => 'Tom', 'age' => '25']]
- 别用
input()或直接取$_POST，它们不解决结构问题 - 正则切分比
explode('[', $key)更健壮，能处理多层嵌套如a[b][c][d] - 注意空值：如果
user[avatar]未提交，$flat里根本没这个键，不会自动补null
验证器必须用还原后的嵌套数组传参
ThinkPHP 的验证器（Validate 类）字段规则写的是点号路径，比如 'user.name' => 'require|alpha'。如果你把扁平数组直接丢给 validate()->check()，它找不到 user.name 字段，校验必然失败。
- 务必先调用
flattenToNested($this->request->param())，再传给验证器 - 不要在验证器规则里写
user[name]—— 验证器不认方括号语法 - 若需保留原始参数用于日志或调试，建议还原前后都存一份，避免反复解析
- TP6 验证器支持
scene场景，但场景字段名仍是点号路径，不影响还原逻辑
为什么不用 param('user.name') 加第三个参数指定来源？
有人试过 $this->request->param('user.name', '', 'post')，期望它能“理解”嵌套，但不行。这个第三个参数只控制数据源（post / get / route），不触发结构解析。
-
param('user.name')底层仍是在扁平数组里找键user.name，而真实键是user[name] - 即使你手动能构造出点号路径的键（比如用
array_change_key_case()改名），也绕不开方括号语义丢失的问题 - 唯一可靠路径：先全量取
param()，再用函数还原，最后喂给业务逻辑或验证器
嵌套参数还原不是可选项，而是必经步骤；最容易被忽略的是验证器那一环——很多人卡在“明明写了规则却没生效”，其实只是参数结构没对上。
