Laravel通知系统默认不外发，需手动配置渠道驱动；发邮件要配MAIL_MAILER及mail.php，微信短信需自定义渠道类；toMail()中须用routeNotificationFor('mail')而非直接取email；队列未运行或配置为sync会导致“卡住”；模板中避免N+1，应预加载关联数据。
Laravel 的通知系统默认不发邮件也不推微信，它只负责“派发”，具体怎么送、送到哪，得你手动配好渠道和驱动。
如何让 Notification::send() 真正发出去
调用 Notification::send() 后没反应？不是代码写错了，大概率是没配通知渠道或驱动。Laravel 默认只注册了 database 和 broadcast 驱动，但这两个都不“外发”——database 写进 notifications 表，broadcast 推给前端监听器，用户根本收不到实际提醒。
- 要发邮件，必须在
.env中配好MAIL_MAILER（比如smtp），并确保config/mail.php里对应驱动的配置完整（尤其是host、port、username、password） - 要发短信或微信模板消息，得自己写一个通知渠道类，继承
NotificationChannel，并在通知类的via()方法里返回它的名字（比如'wechat'） - 运行
php artisan config:clear，别让缓存挡住新配置
toMail() 里不能直接用 $notifiable->email
很多人在通知类的 toMail() 方法里直接取 $notifiable->email，结果发错人或报错。因为 $notifiable 不一定是 User 模型，也可能是任意实现了 Notifiable 的模型，甚至是个临时对象。
Laravel Cloud
下载
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
- 正确做法是：在
toMail()里用$notifiable->routeNotificationFor('mail')，它会自动调用模型上的routeNotificationForMail()方法（可自定义） - 如果模型没定义该方法，Laravel 会 fallback 到
email属性；但一旦你改过字段名（比如叫contact_email），就必须重写这个方法，否则就失效 - 测试时别只用
User::first()，试试传个Order::find(123)进去，看看会不会崩
队列没跑起来导致通知“卡住”
加了 implements ShouldQueue 却发现通知迟迟不发？常见原因不是代码问题，而是队列没真正消费。
- 确认
QUEUE_CONNECTION在.env中设为database、redis或其他可用驱动，而不是默认的sync（sync是同步执行，不走队列） - 运行
php artisan queue:work后，终端必须保持运行状态；用supervisor部署时，检查日志里有没有failed或connection refused - 数据库队列（
database）下，注意jobs表的attempts字段是否已到上限被丢弃，默认是 3 次，失败后进failed_jobs表，得手动处理
通知模板里引用模型关系容易 N+1
在 Blade 模板（如 resources/views/notifications/order_shipped.blade.php）里写 {{ $notifiable->order->product->name }}？小心线上慢成狗。
- 通知类的
toMail()方法执行时，$notifiable是刚从数据库查出来的单个模型，没预加载任何关联 - 解决办法：在触发通知前，显式预加载。比如
Notification::send($user->load('orders.products'), new OrderShipped($order)) - 更稳妥的是，在通知类构造函数里接收已加载好的数据，而不是在模板里现场查 —— 模板只负责渲染，不该承担数据获取责任
通知系统最麻烦的从来不是“怎么写个类”，而是渠道配置、队列状态、模型加载这三块边界处的隐性依赖。漏掉一个，就等于通知发了一半就断在半路。
