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 的授权逻辑和数据库索引这两步。 
