Laravel 官方已弃用 Pusher，主推自托管的 laravel/reverb；若仍用 Pusher，需手动配置 v2 认证头、正确路由、频道鉴权及用户上下文传递，并注意 Reverb 的部署与跨域限制。
Pusher 不再是 Laravel 广播的默认或推荐方案，官方已转向 laravel/reverb 作为首推的自托管广播服务器；若仍需用 Pusher，必须手动配置并注意其 API v1 已停用、v2 的认证机制和事件命名规则变更。
为什么 pusher-php-server v7+ 无法通过 authEndpoint 验证？
Pusher v2 要求所有私有/存在频道的鉴权请求必须携带 X-Pusher-Key 和 X-Pusher-Socket-ID 头，并返回严格格式的 JSON（含 auth 字段），而旧版 Laravel 的 Broadcast::routes() 默认不校验这些头。
- 确保在
routes/channels.php中显式启用鉴权路由：Broadcast::routes(['middleware' => ['web', 'auth:sanctum']]);
- 在
config/broadcasting.php的pusher配置中，host必须设为api-region.pusher.com（如api-us2.pusher.com），不能用ws-*.pusher.com -
前端初始化时，
authEndpoint必须指向 Laravel 的/broadcasting/auth，且该端点需返回形如{"auth":"v1...:..."}的响应，不能多字段、不能带空格
Broadcast::channel() 回调里 $user 为什么是 null？
因为 Sanctum 或 Passport 的中间件未正确传递用户上下文到广播通道闭包——Laravel 广播鉴权不走常规 HTTP 请求生命周期，而是复用当前会话或 Token，但默认不自动解析。
- 确认
config/broadcasting.php中default已设为pusher，且connections.pusher.options.cluster与 Pusher 控制台一致（如us2） - 在
app/Providers/BroadcastServiceProvider.php的boot()方法中，显式绑定用户解析逻辑：Broadcast::channel('chat.{roomId}', function ($user, $roomId) { return $user && $user->can('view', Room::findOrFail($roomId)); }); - 若使用 Sanctum，确保请求携带有效的
Authorization: Bearer {token}，且该 token 已关联用户；web中间件对广播鉴权无效，必须用auth:sanctum
如何让 Reverb 替代 Pusher 实现零成本广播？
Reverb 是 Laravel 官方维护的高性能、纯 PHP 广播服务器，无需第三方服务，但需额外启动进程，且不兼容 Pusher 的客户端 SDK 兼容层（除非启用 pusher 兼容模式）。
- 安装：
composer require laravel/reverb
- 发布配置：
php artisan vendor:publish --provider="Laravel\Reverb\ReverbServiceProvider" --tag="reverb-config"
- 启动服务：
php artisan reverb:start
，并确保BROADCAST_CONNECTION=reverb在.env中生效 - 前端改用 Reverb 客户端：
import { createClient } from 'laravel-reverb'; const reverb = createClient({ key: import.meta.env.VITE_REVERB_APP_KEY, wsHost: import.meta.env.VITE_REVERB_HOST, wsPort: import.meta.env.VITE_REVERB_PORT || 8080, wssPort: import.meta.env.VITE_REVERB_SSL_PORT || 443, forceTLS: (import.meta.env.VITE_REVERB_SCHEME || 'https') === 'https', });
真正麻烦的是跨域和 HTTPS 场景下的 WebSocket 连接：Reverb 默认只监听 localhost，生产环境必须配置 REVERB_HOST=your-domain.com 并反向代理 WebSocket 流量；Pusher 则天然规避此问题，但代价是费用和厂商锁定。
