URL参数最常用但最危险；推荐连接后首条消息发带时间戳和nonce的认证消息并严格校验；Cookie方案在跨域前后端分离场景基本不可行；验证失败须返回明确错误码如4001/4002/4003。
WebSocket连接时怎么传Token？URL参数最常用但最危险
标准WebSocket API不支持在握手阶段设置Authorization请求头，所以前端没法像调REST接口那样直接塞Bearer xxx。URL参数是开发者第一反应，但真用在生产环境，等于把钥匙贴在门上。
- Token会完整出现在Nginx/Access日志里，运维、监控、审计系统都可能留存明文
- 浏览器地址栏可见，用户一不小心复制链接就泄露；DevTools Network面板里也一览无余
- CDN、代理、网关若做URL缓存或重写，可能意外透传甚至记录该参数
- 临时Token若没设短过期（比如≤5分钟），连接又长时保持，风险直接翻倍
只建议在本地调试、内网工具、或配合one-time-use且exp≤120s的JWT时用——不是“能跑通就行”，而是“跑通了也得立刻切掉”。
客户端首次消息发Token：可行，但必须加防重放和时效校验
连接建立后，立刻发一条带签名的认证消息（比如{ type: "auth", token: "xxx", ts: 1741832480123", nonce: "abc123" }），服务端收到后验证再决定是否升级为有效会话。这绕开了URL限制，也比Cookie方案更可控。
- 必须校验
ts时间戳，允许窗口一般≤30秒，超时即拒收 -
nonce要服务端内存/Redis去重，单次使用即失效，防止重放攻击 - 不能等“第一条业务消息”才校验——恶意客户端可以连上来光发心跳，不发任何
auth - 服务端需在连接对象上标记
isAuthenticated: false，未通过前拒绝所有非auth类型消息
示例判断逻辑：if (!socket.isAuthenticated && message.type !== 'auth') { socket.close(4001, 'Unauthorized'); return; }
为什么不用Cookie自动带Token？前后端分离场景下基本不可行
WebSocket握手本质是HTTP Upgrade请求，理论上支持Cookie携带。但前提是：前端域名与后端WebSocket域名完全一致，且协议、端口、路径满足SameSite策略——而真实项目中，前端常跑在https://app.example.com，WS服务却在wss://ws.example.com或wss://api.example.com。
- 跨域时浏览器默认不发送Cookie，即使设了
withCredentials: true也无效（WebSocket API根本不提供这个选项） - 后端若强行读
Cookie字段，大概率拿到空值，或旧会话残留的无效凭证 - Session Cookie通常绑定User-Agent/IP，而移动端切网络、桌面端切WiFi都会导致IP突变，引发频繁掉线重连
除非你明确控制全栈部署拓扑（比如Nginx反向代理统一入口，且所有资源同域），否则别碰这条路。
服务端验证失败时，别只关连接——要明确返回错误码和原因
很多实现验证不通过就直接socket.close()，结果前端只看到WebSocket closed abnormally，根本不知道是Token过期、签名错、还是时间戳超窗。
- 务必在
close时传入标准状态码：如4001（Invalid Token）、4002（Expired）、4003（Replay Attack） - 可在
reason字段附简短提示（注意长度限制，一般≤123字节），比如"ts expired: now=1741832490, exp=1741832480" - 前端监听
onclose时应解析event.code，区分处理：4001/4002触发重新登录，4003则直接销毁当前页面Token缓存
漏掉这步，线上问题排查成本会指数级上升——你永远不知道是前端没传Token，还是服务端校验逻辑漏了分支。
真正卡住人的从来不是“怎么传”，而是“传了之后怎么不让它被截、被重放、被误用”。时间戳、nonce、短生命周期、服务端强状态管理，缺一不可。
