collection::pluck() 支持嵌套提取（如 'author.name'）、去重需链式调用 unique()，pluck('name', 'id') 返回键值对集合；where() 仅内存过滤且严格相等；map() 返回新集合，transform() 修改原集合；diff()/intersect() 按主键比较，groupby() 需返回标量值且依赖预加载。
Collection::pluck() 不只是取 ID，还能嵌套提取和去重
很多人把 pluck() 当成单纯取字段的工具，比如 $users->pluck('id')，但它支持多级嵌套和去重逻辑。当你从关联集合里取子项字段时，用点号语法即可：$posts->pluck('author.name') 会自动遍历每个 Post 模型的 author 关联并提取 name；如果某个 Post 的 author 为 null，对应位置返回 null，不会报错。
去重要加 ->unique() 链式调用，但注意：默认按值比较，若需按字段去重得传参，例如 $users->pluck('email')->unique('email')（其实等价于直接 unique()，因为 email 是当前集合值）；更常见的是先 pluck('role_id') 再 unique() 得到不重复的角色 ID 数组。
容易踩的坑：
-
pluck('name', 'id')返回的是「键值对」集合（id作键，name作值），不是纯数值数组，后续调用toArray()会生成关联数组，别误当索引数组用 - 对空集合调用
pluck()返回空集合，不是null或空数组，判断时要用$collection->isEmpty()，而非empty($collection->pluck(...))
where() 和 whereIn() 在 Collection 层不是 SQL 替代品
Collection::where() 是内存中过滤，它不生成 SQL，也不触发数据库查询——这点必须明确。它只对已加载进内存的模型实例生效，且匹配逻辑是严格相等（===），不支持模糊、范围或 null 判断（比如 where('status', '!=', null) 会失败）。
真正要用数据库层过滤，必须回到 Query Builder：User::where('status', 'active')->get()；而 $users->where('status', 'active') 只适合在已有集合上做轻量二次筛选，比如预加载后按 UI 条件临时分组。
whereNotIn() 同理，只在集合内存中跑，且要求第二个参数是数组。若你传了 Collection 实例，得先 ->all() 或 ->toArray()，否则会抛 ArrayAccess 错误。
性能提醒：10 万条模型加载进内存再 where() 过滤，比直接 SQL WHERE 慢两个数量级，也吃光 PHP 内存。
map() 和 transform() 的边界很关键
map() 返回新集合，原集合不变；transform() 是就地修改，直接改原集合内容。选哪个取决于你是否需要保留原始数据。
常见误用是拿 map() 做副作用操作，比如：
$users->map(function ($u) {
$u->sendWelcomeEmail(); // ❌ 错！map 应该返回值，否则结果集合全是 null
return $u;
});
正确做法是用 each() 或普通 foreach：
$users->each(function ($u) {
$u->sendWelcomeEmail();
});
另一个陷阱：在 map() 闭包里修改模型属性（如 $u->status = 'processed'）不会自动保存到数据库，这只是对象状态变更。若后续要批量保存，得额外调用 save() 或用 upsert()。
diff()、intersect() 和 groupBy() 处理关联状态最实用
当你要对比两批用户集合（比如「昨日活跃用户」vs「今日新增用户」），diff() 和 intersect() 比手写循环快得多，且自动按模型主键去重比较——前提是两个集合里的模型来自同一类、主键类型一致。
groupBy() 最常被低估的用法是按关联存在性分组。例如：
$users->groupBy(function ($u) {
return $u->posts->isNotEmpty() ? 'has_posts' : 'no_posts';
});
这比在 Blade 模板里反复判断 $user->posts->count() 更高效，也避免 N+1（前提是 posts 已预加载）。
注意：groupBy() 的回调返回值会成为键名，若返回对象或数组，PHP 会强制转成字符串（通常是 "Object"），导致所有项归到同一组——所以务必返回标量值。
复杂点在于：这些方法都依赖模型已加载的关联数据，没预加载就调用 $u->posts，会触发懒加载，反而放大 N+1 问题。预加载永远是前提。
