Laravel集合each->method()仅在无参、不抛异常、集合非空、元素支持该方法时“看似好用”；空集合静默跳过，传参需闭包或宏，I/O操作须加try/catch或改用队列。
直接说结论：Laravel 集合的 each->method() 不是万能批量调用语法，它只对**无参、不抛异常、集合非空、且元素是支持该方法的对象**这四个条件同时满足时才“看起来好用”；多数线上问题都卡在这几个隐性前提上。
为什么 each->save() 有时没反应，也不报错
根本原因是集合为空时，each->xxx() 完全静默——既不执行，也不提示。开发时用测试数据跑通了，上线后查不到符合条件的模型，结果就是“什么都没发生”。
- 检查集合长度：
$users->count()或$users->isNotEmpty()，别只信逻辑条件 - 空集合场景下，想强制触发日志或 fallback 行为，必须显式判断：
if ($users->isNotEmpty()) { $users->each->save(); } -
each->xxx()不会抛出Collection is empty类错误，它只是跳过——这点和first()或sole()的行为逻辑完全不同
each->notify($message) 为什么会报错“Too few arguments”
Laravel 原生高阶代理不支持传参。each->notify($message) 这种写法在 PHP 层面就非法：魔术方法 __get() 只能捕获属性访问，无法接收方法参数。
- 正确做法是用闭包：
$users->each(fn($u) => $u->notify($message)); - 如果想保留“高阶”调用风格，得靠宏（Macro）封装参数逻辑：
Collection::macro('notify', function ($message) { return $this->each(fn($u) => $u->notify($message)); });，然后调用$users->notify('updated') - 注意：宏注册必须在
AppServiceProvider@boot()中完成，且不能放在条件分支里，否则可能漏加载
each->sendEmail() 中一个失败，整个链路就中断
高阶消息传递没有内置容错机制。只要某个模型调用 sendEmail() 抛出异常（比如邮件配置错、网络超时），后续所有模型都不会再执行。
- 生产环境别用
each->xxx()处理 I/O 操作，改用带try/catch的闭包遍历 - 示例：
$users->each(function ($u) { try { $u->sendEmail(); } catch (\Exception $e) { \Log::error("Failed to email user {$u->id}", ['exception' => $e]); } }); - 更彻底的解法是把单次调用封装成队列任务，用 Laravel 队列的重试 + 失败表（
failed_jobs）来兜底
什么时候该放弃 each->xxx()，改用 map() 或 filter()
当你需要“转换+过滤+聚合”混合操作，或者要从调用结果中提取信息（比如收集成功 ID、统计失败数），each->xxx() 就完全不够用了——它只负责执行，不返回任何中间态数据。
- 想获取所有更新后的 ID：
$users->map->save()->map->id->toArray()（前提是save()返回模型实例） - 想筛选出能发邮件的用户再批量处理：
$users->filter->canEmail()->each->sendEmail() - 注意：
map->xxx()和each->xxx()都依赖目标方法存在且无参；若save()被重写为返回布尔值，map->save()就会得到一堆true/false，而非模型
最容易被忽略的一点：高阶消息传递本质是语法糖，不是执行引擎。它不改变底层循环逻辑，也不提供事务、重试、日志埋点等生产必需能力。真正在意成功率、可观测性和可维护性，就别图那一行代码的简洁。
