Laravel 10 使用 Pusher 实现广播需三处配置严格一致：.env 中 BROADCAST_DRIVER=pusher、config/broadcasting.php 的 pusher 连接配置（含正确 cluster）、BroadcastServiceProvider 启用；前端须用 MIX_ 前缀暴露密钥，私有频道鉴权接口必须返回 {"auth": "xxx:yyy"}，事件类与前端监听名称须完全匹配。
Laravel 10 使用 Pusher 实现广播事件推送，关键不在“装完就能用”，而在于三处配置必须严丝合缝、前后一致，且每一步都需验证生效。错一个环节，前端就收不到事件，控制台还可能静默失败。
Pusher 驱动的三处硬性配置
不是只改 .env 就完事——以下三处必须完全对齐：
- BROADCAST_DRIVER=pusher：这是总开关，必须写在 .env 中，且不能被注释或拼错；设成 redis 或 log 会直接跳过 Pusher 流程
- config/broadcasting.php 中 connections.pusher 的完整配置：包括 key、secret、app_id 和 options.cluster（2026 年新应用默认为 mt1，填 us2/eu/ap1 等旧集群将连接失败，无报错）
- App\Providers\BroadcastServiceProvider 必须启用：检查 config/app.php 的 providers 数组，确保该服务提供者未被注释；否则 /api/broadcasting/auth 路由根本不存在，私有频道鉴权直接 404
环境变量与前端注入规则
前端 JS 无法直接读取 PUSHER_APP_KEY，必须显式暴露：
- .env 中要写 MIX_PUSHER_APP_KEY=xxx（带 MIX_ 前缀），而不是 PUSHER_APP_KEY=xxx
- Laravel Mix 编译时才把以 MIX_ 开头的变量注入到 process.env；漏掉前缀，Echo 初始化会报 Invalid key
- 前端代码中必须用 process.env.MIX_PUSHER_APP_KEY，且 cluster 同样要对应 process.env.MIX_PUSHER_APP_CLUSTER
私有频道鉴权接口要点
前端调用 Echo.private('chat.123') 时，Laravel 自动发 POST 请求到 /api/broadcasting/auth，这个接口返回内容决定成败：
- 响应状态码必须是 200，但真正起作用的是响应体 JSON
- 必须返回 {"auth": "xxx:yyy"} 格式，字段名必须是 auth，不能是 token 或 data
- 返回 {"error": "unauthorized"} 或空 JSON，前端会卡在 connecting 状态，看似连上了实则没授权
- 频道名大小写和类型必须严格一致：'private-chat.' . (string)$id 和 'private-chat.' . $id（$id 是 int）生成的频道名不同，后端授权通过、前端却订阅失败
事件定义与前端监听对齐
广播能否触达，取决于后端事件定义与前端监听是否“同频”：
- 事件类实现 ShouldBroadcast 接口，并在 broadcastOn() 中返回 PrivateChannel('chat.123') 类型实例
- 若用了 broadcastAs('message.sent')，前端 listen() 必须写 listen('message.sent')，不能沿用类名
- broadcastWith() 中避免传 Eloquent 模型对象，防止序列化触发 N+1 查询；只传 ID、字符串或简单数组
- 每次修改 .env 后，务必运行 php artisan config:clear，否则缓存配置会掩盖错误
