ThinkPHP请求对象怎么获取路由参数-ThinkPHP-PHP中文网

param('id') 是 thinkphp 6.x 中获取路由参数最常用但易错的方式，它合并路由变量、get 和 post 值，且路由变量优先级最高；必须在路由规则中明确定义 :id 占位符，否则返回 null。

thinkphp请求对象怎么获取路由参数

param('id') 是最常用也最容易出错的方式

在 ThinkPHP 6.x 中，param() 是获取路由参数的默认入口，但它不是“只取路由参数”，而是合并了路由变量、GET 和 POST 的值，并且**路由变量优先级最高**。比如访问 /user/123?name=admin，param('name') 拿到的是 GET 的 admin，但 param('id') 拿到的是路由匹配出的 123——前提是路由规则里写了 :id。

常见错误是：URL 看似带值（如 /user/123），但 param('id') 返回 null。原因几乎总是路由定义漏了冒号：Route::get('user', ...) 不行，必须是 Route::get('user/:id', ...)。可选参数写成 :id?，但注意不加 ? 就是必填，匹配失败直接 404。

确保路由规则中明确声明占位符，例如 user/:id 或 article/:id/:slug
多个参数顺序必须和 URL 路径段严格一致，user/:id/:type ≠ user/:type/:id
不要在控制器构造函数里调用 param()，此时路由尚未解析完成，值为空
分组或域名绑定路由时，需确认当前请求命中了对应分组，否则整个路由上下文失效

route('id') 专用于读取原始路由匹配结果

route() 方法只从路由匹配结果中取值，不混入 GET/POST，语义更纯粹。它适合你明确只想知道“URL 路径里被框架解析出来的那个 id 是什么”，尤其当同名 GET 参数可能干扰判断时。

例如，路由定义为 Route::get('api/v1/user/:id', 'Api/User/info')，请求地址是 /api/v1/user/99?format=json，那么：

param('id') → 99（来自路由）
route('id') → 99（仅来自路由）
get('id') → null（因为 id 不在查询字符串中）

注意：route() 只对已成功匹配的路由变量有效；如果路由没配占位符，或匹配失败，返回 null。它也不支持过滤器（如 htmlspecialchars），如需处理，得手动套函数。

Skill Weave Chains — 技能链路由引擎

开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。

下载

为什么 input('id') 拿不到路由参数

input() 是 ThinkPHP 5.x 遗留方法，在 6.x 中默认行为是只读 $_GET 和 $_POST，**完全不包含路由变量**。这是开发者踩坑最多的地方之一：看到文档里说 “input() 获取输入数据”，就以为能通吃，结果在 RESTful 接口里怎么都拿不到 :id。

input('id') 等价于 get('id') ?: post('id')，跟路由无关
想兼容旧代码又需要路由参数？改用 param('id') 或显式 route('id')
中间件中若提前调用了 input()，后续控制器再用 param() 也不会补上路由值——源头就错了

RESTful 场景下推荐组合：param() + only() + 验证

在 API 开发中，通常需要同时提取路径参数（如 :id）、查询参数（如 ?page=2）和 JSON body 字段。这时 param() 的合并能力反而成了优势，但要注意字段冲突和类型安全。

示例：路由 PUT /user/:id，请求体是 JSON {"name":"Alice","email":"a@b.c"}，查询带 ?force=1：

$data = request()->param();
// $data 包含 ['id' => 123, 'name' => 'Alice', 'email' => 'a@b.c', 'force' => '1']

但直接全量用风险高，建议白名单控制：

用 only(['id', 'name', 'email'], 'param') 显式指定字段来源和范围
param('id', 0, 'intval') 强制转整型，避免字符串 ID 导致 SQL 注入或类型误判
对 JSON 请求，param() 自动解析 php://input，但需确保 Content-Type 是 application/json，否则 fallback 到空数组

真正容易被忽略的是：路由参数一旦被 param() 合并进去，就失去了“来源可追溯性”。如果你需要区分“这个 id 是从路径来的还是从 query 来的”，就得拆开用 route('id') 和 get('id') 单独判断——别指望一个方法解决所有问题。