控制器构造函数中param()一定为空，因路由参数解析发生在实例化之后、动作方法执行之前；正确位置是动作方法内、方法参数依赖注入或路由解析后的中间件中。
控制器构造函数里调用 param() 一定为空，这不是 bug，是设计使然——路由参数此时根本还没解析。
为什么构造函数里 param() 拿不到值
ThinkPHP 的请求生命周期中，路由匹配、参数解析发生在控制器实例化之后、动作方法（如 index()、read()）执行之前。构造函数 __construct() 是最早被调用的环节，此时 $this->request 可能尚未注入，或已注入但 param() 内部依赖的路由数据还未填充。
- 直接报错
Call to a member function param() on null：说明$this->request还没绑定 - 返回空数组或
null：说明$this->request存在，但路由参数字段仍是空的 - 即使你手动在构造函数里写
$this->request->param('id')，结果也一样不可靠
正确取路由参数的三个位置
必须把参数获取逻辑放在路由解析完成之后的上下文中：
-
动作方法内部：最稳妥，比如
public function read() { $id = $this->request->param('id'); }或直接param('id') -
依赖注入到方法参数：在动作方法签名里声明
\think\Request $request，框架会自动注入已解析完毕的 Request 对象 -
中间件中：只要中间件注册在路由解析中间件（如
Think\Middleware\LoadLangPack）之后，$request->param()就可用；但别在前置中间件（如日志、跨域）里依赖它
想在构造函数里“预加载”参数？绕不开的坑
硬要在 __construct() 里处理参数，等于对抗框架流程，后果是：
- 改
config/route.php开启'url_param_type' => 1并配合显式路由定义，仍不能保证构造函数时机安全 - 试图用
input('id')替代 —— 它不读路由段，只读$_GET/$_POST，URL 路径里的/user/123中的123不会出现 - 用
$_GET或$_SERVER['PATH_INFO']手动解析 —— 绕过框架路由规则，丢失 pattern 约束、变量类型转换、大小写映射等能力，后续param()行为可能不一致
容易被忽略的细节
哪怕你把代码挪到了动作方法里，仍可能拿不到参数：
- 路由定义漏了冒号：
Route::get('user/:id', ...)写成Route::get('user/id', ...)→param('id')必定返回null - 用了闭包路由但没确认执行时机：闭包内调用
param()是安全的，但若闭包提前 return 或 throw，后续逻辑就断了 - 中间件里先调了
input()，又在控制器里调param()—— 没问题，但别指望两者行为一致；input()始终不包含路由参数
真正要做的，不是让构造函数“变聪明”，而是接受框架的执行顺序：参数属于请求上下文，不是对象初始化的一部分。把逻辑往后移一行，放到动作方法里，问题就消失了。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
