在ThinkPHP框架开发过程中，param()方法常被开发者视为获取请求参数的“万能工具”。然而，这把钥匙并非总能打开所有的锁。当它意外返回null时，问题往往源于请求类型、路由配置或数据来源的误解。要编写出健壮可靠的代码，关键在于深入理解不同方法的适用场景，并严格依据数据来源选择正确的参数获取方式。

param() 方法何时会失效？

你是否曾遇到这样的困惑：URL中明明包含了?id=123查询参数，但调用param('id')却返回了null？这通常并非框架的bug，而是由以下几个常见原因导致的：

• JSON请求的盲区：当请求头Content-Type设置为application/json时，param()方法并不会自动解析请求体中的JSON数据。它仅读取GET参数、POST参数以及路由中定义的变量。
• 强制路由的“吞噬”效应：如果开启了url_route_must（强制路由）配置，类似index.php?s=/user/info这类URL中的查询参数可能会被路由规则“吞没”，导致无论是get()还是param()方法都无法获取到它们。
• PHP配置的限制：当表单提交的字段数量过多，超过了PHP配置项max_input_vars的限制时，超出的字段会被静默截断。此时post()获取到的数据可能为空，param()自然也就跟着失效了。

GET/POST 表单该用 get() 还是 param()？

在处理传统的表单提交或URL查询参数时，一个核心原则是：优先使用get()或post()方法，而非图省事直接使用param()。原因在于它们的行为存在本质区别：

• get('name')：该方法仅从$_GET超全局变量中读取数据，不进行任何合并、修剪（trim）或类型转换，获取的是最原始的未处理值。
• post('name')：同理，它只读取$_POST数据。这意味着，即使前端传来一个空字符串''，它也会原样返回，而不会被转换成null。
• param('name')：这个方法会进行“智能”处理，包括自动trim空格、将字符串'123'转为整数123，甚至将空字符串和空数组统一转为null。这种特性适合在业务逻辑层直接使用“清洗”后的数据，但不适合在需要原始值进行严格校验或精确判断的场景中使用。

JSON 接口必须使用 input() 或 json() 方法

随着前后端分离架构的普及，JSON接口越来越常见。如果前端发送了一个如下的请求：

fetch({
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ id: 1 })
})

那么下面这两种写法都会让你失望：

• param('id') → 返回 null（原因如前所述，不解析JSON请求体）
• post('id') → 同样返回 null（因为数据不在$_POST里）

正确的解决方案只有两种：

• 使用 input('id')：这个方法内部会尝试解析JSON请求体。但需注意，它通常只支持顶层的字段。对于嵌套结构如{ "user": { "id": 1 } }，你无法直接通过input('user.id')点语法来获取。
• 使用 json(true)：这是最彻底的方法。它会将整个JSON请求体完整解析为数组，之后你就可以像操作普通数组一样取值了。例如：$data = \think\facade\Request::json(true); $id = $data['id'] ?? null;

TP6 中 request 对象如何正确获取？

从ThinkPHP 5.x升级到6.x的开发者需要特别注意一个重大变化：Request::instance()这个经典的静态调用方式已被彻底移除，继续使用会导致Fatal error。在TP6中，获取请求对象只剩下三个官方推荐入口：

• 控制器方法参数注入：这是最优雅的方式，直接在控制器方法中声明类型即可：public function index(\think\Request $request)
• 助手函数：使用request()助手函数来获取请求对象：request()->param('id')
• 门面类：通过门面类进行静态调用：\think\facade\Request::param('id')

还有一个细节值得留意：在TP6中，input('name')方法默认不会读取路由变量。如果你需要它读取，必须显式地加上过滤器参数，例如input('name', '', 's')。而param()方法则依然保持着合并GET、POST和路由变量的特性。