laravel模型中直接使用request()是错误的，因其违反分层原则，导致测试难mock、命令行报错、静态分析失效；正确做法是参数由控制器传入模型作用域，或封装为独立filterservice类。
模型里直接用 request() 是错的
Laravel 模型（Model）是数据层抽象，不该耦合 HTTP 请求逻辑。你在模型里写 request()->query('foo') 或 Request::query('foo')，看似能跑通，但会带来三个实际问题：测试无法 mock 请求、命令行调用模型时抛 RuntimeException: Request not available、IDE 无法静态分析参数来源。
正确传递参数的两种场景和做法
参数必须从外部传入，模型只负责接收和处理：
- 控制器调用时：显式把 GET 参数作为方法参数传进去
// UserController.php<br>public function index()<br>{<br> $status = request()->query('status', 'active');<br> $users = User::filterByStatus($status)->get();<br>} - 模型作用域中：定义带参数的作用域方法，不依赖全局请求
// User.php<br>public function scopeFilterByStatus($query, string $status)<br>{<br> return $query->where('status', $status);<br>}
request() 在模型里偶尔“能用”但绝不该用
某些人发现模型里写 request()->has('search') 偶尔不报错，是因为 Laravel 的服务容器在 HTTP 生命周期内已绑定 Illuminate\Http\Request 实例。但这属于隐式依赖，且：
- Artisan 命令执行时
request()返回 null，调用->query()直接报错 - 单元测试中若未手动绑定 Request，
request()为空，断言失败但原因难排查 - PHPStan / Psalm 静态分析会标出 “Call to an undefined method on mixed”
需要复用过滤逻辑？抽成独立类或 Service
如果多个模型都要根据相同 GET 参数做筛选（比如分页、搜索、状态），别在每个模型里重复写作用域，而是封装为可复用结构：
- 定义
FilterService类，构造时注入Request，提供applyToBuilder(Builder $builder)方法 - 控制器中实例化并调用：
(new FilterService())->applyToBuilder(User::query()) - 模型里完全不碰
request()，只接收已处理好的查询条件数组或闭包
真正难的不是“怎么取参数”，而是让模型保持无状态、可预测、可测试——这点容易被赶工期时忽略。
