ThinkPHP控制器中如何正确获取GET和POST参数【基础】

工作这么多年，跟参数获取打过无数交道，最深的体会就是：大部分情况下，你真的不用自己去判断参数到底是 GET 还是 POST 来的。param() 方法会帮你把 $_GET、$_POST 甚至路由参数全都合并在一起，然后按一个明确的优先级（POST > GET > route）来取值。这样一来，手动判断请求类型这事儿，基本可以省了。

不过，常见的坑也正出在这里。比如，有人习惯写 input('id')，却不指定来源，结果在 POST 请求里，意外拿到了 GET 中同名的参数。再比如，想用 input('data.') 批量取子数组，但漏了那个关键的末尾点号，最后数据就是取不到。

所以，param() 的正确用法，有几个关键点值得留意：

• $id = $request->param('id')：参数不存在时，直接返回 null，不会触发 Notice 报错。
• $id = $request->param('id', 0)：用这种方式指定默认值，可以避免空值引发后续逻辑异常。
• $id = $request->param('id/d', 1)：类型后缀 /d 很实用——如果传了 id=abc 这种不合法的输入，它会直接转为 0，比手工 (int) 转换要安全得多。
• $data = $request->param('user.')：要取 user[name]、user[age] 这类嵌套结构，末尾点号必须带上，否则框架不会帮你递归解析。

你可能会问，那究竟什么时候才需要显式地用 get() 或 post() 呢？答案是：当框架的自动合并行为开始干扰业务逻辑的时候。举个例子，后端接口既支持 URL 查询，又接受表单提交，但业务要求 URL 里的 ?page=2 这样的分页参数必须绝对生效，不能被 POST 参数覆盖。这时候如果用 param('page')，结果可能就不可控了。

值得注意的是，get() 和 post() 并不局限于传统的 GET/POST 请求。它对 PUT、DELETE 等方法也是有效的，但它只读取对应的原始来源（$_GET 或 $_POST），不处理 JSON body 或 multipart 表单中的非文件字段。

• $page = $request->get('page')：只认 URL 查询串，哪怕 POST 里也提交了同名字段，不受影响。
• $content = $request->post('content/s')：/s 后缀只对 POST 数据生效，对 GET 是无效的——类型过滤是跟来源绑定的。
• 如果表单用的是 enctype="multipart/form-data" 提交，$request->param() 会跳过所有文件字段，但 $request->post() 仍然能正常读取到普通文本字段。

接下来聊聊大家经常混用的 input() 和 $request->xxx()。其实，input() 是全局助手函数，本质上是封装了对 Request 对象的调用，语法更紧凑；而 $request->param() 这类写法是面向对象的，适合依赖注入或需要复用请求实例的场景。两者的能力一模一样，选一种并保持项目统一就行。

一个容易踩的坑是：input('name') 的默认行为是自动探测，等价于 param()，并不是只读 GET。新手常常以为 input('name') 就是取 GET，其实它优先取 POST。只有写成 input('post.name') 才是强制限定来源。

这里有几组等价关系，可以帮你快速对照：

• input('id') ≡ $request->param('id')
• input('post.id') ≡ $request->post('id')
• input('get.name/s') ≡ $request->get('name', '', 'htmlspecialchars')
• 千万不要混用：同一个控制器里，别一会儿用 input()，一会儿又用 $request->get()，这样很容易遗漏过滤规则或默认值逻辑。

最后一件事，也是最重要的：绝对不要直接去读 $_GET 或 $_POST。

绕过框架直接操作这些超全局变量，等于放弃了所有安全防护：没有默认值兜底、没有类型转换、没有 XSS 过滤、不支持嵌套数组解析，而且参数缺失时会直接触发 Notice: Undefined index 报错。

尤其是现在 RESTful 接口和小程序场景越来越多，前端经常用 fetch 配合 JSON body 发送数据。这种情况下，$_POST 是空的，但 $request->param() 可以通过中间件解析出 JSON 内容。如果直接读超全局变量，数据根本收不到。

总结几个容易被忽略的细节：

• JSON 请求体（Content-Type: application/json）需要框架中间件解析，$_POST 始终为空，而 $request->param() 能正常取值。
• $_GET 和 $_POST 不经过任何过滤，恶意构造的 ?id= 会原样透出。
• 像 user[name]=a&user[age]=b 这样的数组参数，$_POST['user'] 拿到的是字符串而不是数组，只有 $request->param('user.') 才能正确解析。

还有一个容易被忽略的点：类型后缀的绑定逻辑。同一个 /d 后缀，在 param('id/d') 和 post('id/d') 中行为一致，但在 get('id/d') 中，它只对 URL 查询串生效。如果你写了 get('id/d')，但传了 ?id=abc，结果仍然是 0。可如果传了 ?id=123abc，框架会截断取整，而不是直接报错或丢弃——这个行为还是和手工 (int) 有点区别的。