Laravel怎么使用Notification通知_Laravel消息推送系统教程【提醒】

via()方法写错会导致通知静默失败，必须返回已注册渠道名的字符串数组，如[‘mail’,’database’]；数据库需加notifiable_id+notifiable_type联合索引；广播通知要确保频道类型、鉴权和前端订阅方式严格匹配。

via() 方法写错，通知就发不出去

通知类里 via() 是开关，不是可有可无的装饰。它决定消息走哪条路，返回空数组、拼错渠道名（比如写成 'mails' 而不是 'mail'），或者返回了未配置的渠道（如写了 'vonage' 却没装包也没配 config/services.php），结果就是静默失败——没报错，但用户啥也收不到。

• via() 必须返回字符串数组，且每个值必须是 laravel 已注册的渠道名：常见的是 'mail'、'database'、'broadcast'
• 如果只存数据库，就写 return ['database'];；想同时发邮件+存库，就写 return ['mail', 'database'];
• 第三方渠道（如 Twilio、Slack）要先 composer require laravel-notification-channels/twilio，再在 via() 里加对应名字（如 'twilio'），并实现 toTwilio()

数据库通知查得慢？别忘了加联合索引

用 database 渠道时，Laravel 自动把通知写进 notifications 表，但默认表结构没有针对查询优化。当你调用 $user->unreadNotifications 或分页拉取时，如果用户通知量上万，notifiable_id 和 notifiable_type 没索引，就会全表扫描，接口直接卡住。

• 迁移建表后，手动加联合索引：php artisan make:migration add_index_to_notifications_table，在 up() 里写 $table->index(['notifiable_id', 'notifiable_type']);
• data 字段是 json 序列化存的，别在里面查字段内容——它不支持高效检索，需要查内容就另建扩展字段
• 标记已读用 $user->notifications()->where('id', $id)->markAsRead()，比先 find() 再 markAsRead() 更省一次查询

广播通知前端收不到？先看频道类型和鉴权是否对得上

用 broadcast 渠道时，90% 的“收不到”问题出在频道类型和后端鉴权逻辑不匹配。比如你 broadcastOn() 返回 new privateChannel('user.' . $user->id)，前端却用 channel()（公开频道方法）去订阅，或没配 authEndpoint，请求直接 403 被拒。

• 私有频道（PrivateChannel）必须在 routes/channels.php 显式授权，返回 true 或具体权限判断逻辑
• 前端 Laravel echo 订阅必须用 private() 方法，且频道名严格一致（注意大小写、数字类型：整数 123 和字符串 '123' 拼出来是两个频道）
• BROADCAST_DRIVER=redis 时，确保 php artisan queue:work 在跑——Redis 广播依赖队列进程转发事件，不是实时直连

通知类里传模型实例，小心 N+1 查询和序列化陷阱

很多人习惯在通知构造函数里直接塞一个 $order 模型，然后在 toMail() 或 toBroadcast() 里调用 $this->order->user->name。这看着方便，但会触发延迟加载，尤其在队列中执行时，可能重复查库；更糟的是，Eloquent 模型序列化进 Redis 或广播 payload 时，会把整个关系链拖进去，体积暴增甚至失败。

• 只传必要字段：构造函数收 $orderId，在 toMail() 里用 Order::find($this->orderId) 查一次，或提前用 load() 预加载
• toBroadcast() 返回的数据必须是纯数组，不能含模型对象；用 toArray() 或手动构造键值对
• 若通知需频繁触发（如每秒多条），务必让通知类实现 ShouldQueue 接口，避免阻塞 http 请求

通知系统本身不难搭，难的是每条链路都得对齐：渠道配置、数据格式、频道权限、前端监听，漏掉任意一环，消息就停在半路。最常被跳过的其实是 routes/channels.php 的授权逻辑和数据库索引这两步。