Laravel模型查询结果默认是Collection，应优先用where等Query Builder方法将条件下推至数据库；仅当逻辑无法SQL化（如JSON解析、PHP函数计算）时才用filter()等Collection方法，避免全量加载导致OOM。
Laravel 的模型查询结果本身就是 Collection，不需要“转集合”这一步；所谓“筛选”本质是调用 Collection 的链式方法，但直接在查询后调用容易踩内存和性能坑。
为什么不能先 get() 再用 filter() 做业务筛选
很多人写成 User::all()->filter(...) 或 User::get()->where(...)，看着链式很爽，实际把全部数据从数据库捞到 PHP 内存里再筛——10 万条用户记录，哪怕只取 3 个字段，也极易 OOM 或拖慢响应。
真正该做的是：能下推到数据库的条件，一律用 where、when 等 Query Builder 方法；只有无法 SQL 化的逻辑（比如 JSON 字段解析后判断、调用 PHP 函数计算），才用 Collection 方法。
- 数据库能做的（字段比较、范围、关联存在性）→ 用
where()、whereHas()、whereIn() - PHP 才能做的（
strtotime()处理、str_contains()、对象属性动态计算）→ 先get()，再filter()或map() - 不确定是否要全量加载？加
dd($query->toSql(), $query->getBindings())看生成的 SQL
filter() 和 where() 混用时的常见错误现象
典型翻车现场：User::get()->filter(fn($u) => $u->is_active)->where('name', 'like', '%admin%') —— 这里 where() 是 Collection 方法，不是 Query Builder，它只支持数组键名匹配（等值），不支持 like、> 等操作符，会静默返回空集合或报错 Call to undefined method Illuminate\Support\Collection::where()（取决于 Laravel 版本）。
-
Collection::where()只接受key === value的严格匹配，且 key 必须是模型属性名（如'status'），不能是'status like %active%' -
Collection::filter()参数是闭包，可写任意 PHP 逻辑，但闭包内访问不存在属性会触发__get或报Undefined property - 想模糊搜索？用
filter(fn($u) => str_contains($u->name, 'admin'))，别硬套where()
什么时候必须用 Collection 筛选？附轻量示例
场景明确：数据已取出，且筛选依赖运行时 PHP 状态（如当前用户权限、本地配置、第三方 API 返回值），或字段内容是 JSON/serialized，需解码后判断。
例如：
$users = User::select('id', 'meta')->get();
$activeAdmins = $users->filter(function ($user) {
$meta = json_decode($user->meta, true) ?: [];
return $meta['role'] ?? null === 'admin'
&& now()->lt(Carbon::parse($meta['expires_at'] ?? '')); // 依赖 Carbon 实例
});
- 这种逻辑无法写进 SQL，只能 Collection 处理
- 注意：如果
$users数据量大，考虑用chunkById()分批处理，避免内存爆炸 - 别在
filter()里调 DB 查询（比如$user->posts->count()），那会 N+1；应提前用withCount('posts')
最常被忽略的一点：Collection 方法返回的是新实例，不会修改原集合；链式调用时，中间某步用了 values() 或 keyBy()，后续 filter() 的键可能不再是 ID，而是数字索引——这时候用 firstWhere() 就会失效。别假设键永远可用，需要时显式 keyBy('id') 或用 first() + 闭包。
