websocket连接可在握手阶段自动携带同源cookie，前提是服务端返回access-control-allow-credentials:true且指定具体origin；token则需手动拼入url查询参数并encodeuricomponent编码，服务端从req.url解析校验。
WebSocket 连接本身不自动携带 HTTP 的 Cookie 或 Authorization 头，但你可以在建立连接时（即发起 new WebSocket(url)）让浏览器自动带上当前域下的 Cookie，前提是满足同源或已配置 CORS + credentials。Token 方式则需手动拼接到 URL 查询参数中（如 ws://example.com?token=xxx），服务端再从中提取验证。
用 Cookie 自动验证（推荐用于同域/可信跨域场景）
浏览器在 WebSocket 握手请求（HTTP Upgrade）时，默认会附带同源 Cookie（包括 HttpOnly 和 Secure 的），无需前端额外操作。关键是要确保：
- 前端页面与 WebSocket 服务端在同一主域下（如都是
https://app.example.com），或子域间已正确配置document.domain（较少用） - 若跨域（如前端在
https://admin.example.com，WS 在wss://api.example.com），后端必须在 HTTP 握手响应中返回：Access-Control-Allow-Origin: https://admin.example.comAccess-Control-Allow-Credentials: true
前端创建连接时也需显式启用 credentials：new WebSocket('wss://api.example.com', { credentials: 'include' });（注意：标准 WebSocket 构造函数不支持第二个参数传 options；实际应使用new WebSocket(url)，credentials 由浏览器根据当前页面上下文和 CORS 响应自动决定）——更准确地说：只要页面 Cookie 可发送、且服务端响应了Access-Control-Allow-Credentials: true，浏览器就会在 Upgrade 请求中带上 Cookie - 服务端（如 Node.js + ws 库）需在升级前检查请求头中的
cookie字段，解析并校验 session（例如用cookie-parser+express-session中间件预处理，或手动解析）
用 Token 拼在 URL 中验证（适合跨域、移动端、或需显式控制认证的场景）
由于 WebSocket 不支持自定义请求头，最通用的方式是把 token 放在 WebSocket URL 的查询参数里：
- 前端登录成功后拿到 JWT 或临时 token，连接时写成：
const ws = new WebSocket(`wss://api.example.com?token=${encodeURIComponent(token)}`); - 服务端（如 ws 库）可在
upgrade事件中获取 URL 查询字符串：socket.on('upgrade', (req) => { const url = new URL(req.url, 'http://f'); const token = url.searchParams.get('token'); /* 校验 token */ }); - 注意：Token 不要放在 URL 中传输敏感信息（如长期有效的密钥），建议用短期有效、绑定 IP/User-Agent 的临时 token；避免日志记录完整 URL 泄露 token
服务端验证 session/token 的常见做法
无论用 Cookie 还是 Token，服务端最终都要做三件事：
-
解析凭证：从
req.headers.cookie提取 sessionId，或从 URL 解析 token - 校验有效性：查 Redis / 数据库确认 session 未过期、未登出；或用 JWT 库验证签名和有效期
-
挂载用户信息：验证通过后，把
userId、roles等存到 socket 实例上（如socket.userId = 123），后续消息处理可直接使用
不推荐的做法和注意事项
以下方式存在明显风险或不可行，应避免：
- 试图在 WebSocket 连接建立后，先发一条“登录”消息再开始业务 —— 此时连接已打开，无法阻止未授权客户端收发数据，属于事后验证，安全性低
- 把 token 存在 localStorage 后拼进 URL —— 若 localStorage 被 XSS 窃取，token 即泄露；优先用 HttpOnly Cookie 存 session ID
- 在 WebSocket 上重复使用登录接口的 cookie/session 机制，却不校验 CSRF（WebSocket 本身不受同源策略限制，但 Cookie 验证本身已依赖域名隔离，一般无需额外 CSRF 防护）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
