最常用且兼容性最好的方式是将 Token 作为 URL 查询参数，用 URLSearchParams 拼接到 SSE 的 URL 中；需确保 Token 已获取、安全编码、HTTPS 传输，并在后端校验签名与有效期。
在 JavaScript 中使用 SSE（Server-Sent Events）时，不能直接通过 fetch 或 XMLHttpRequest 那样的方式设置请求头（如 Authorization），因为 EventSource 构造函数只接受一个 URL 字符串，不支持传入配置对象。所以，若需传递初始化鉴权 Token，最常用且兼容性最好的方式是：将 Token 作为 URL 查询参数，用 URLSearchParams 拼接到 SSE 的 URL 中。
1. 使用 URLSearchParams 构建带 Token 的 SSE URL
这是最直接、浏览器原生支持的做法。Token 作为查询参数附加在 URL 后，后端从 req.url 或查询字符串中解析即可（注意：仅适用于非敏感场景或短期有效 Token；生产环境建议配合 HTTPS + 短期有效期 + 后端校验）。
- 确保 Token 已经获取（例如登录后存在 localStorage 或变量中）
- 用
URLSearchParams安全编码参数值，避免特殊字符导致 URL 解析错误 - 拼接后的 URL 传给
new EventSource()
示例代码：
const token = localStorage.getItem('auth_token') || 'your-jwt-token';
const baseUrl = '/api/events';
// 构建查询参数
const params = new URLSearchParams();
params.set('token', token); // 自动 encodeURIComponent
// 生成完整 URL
const sseUrl = `${baseUrl}?${params.toString()}`;
// 创建 EventSource
const eventSource = new EventSource(sseUrl);
eventSource.onmessage = (e) => {
console.log('收到消息:', e.data);
};
eventSource.onerror = (err) => {
console.error('SSE 连接出错:', err);
};
2. 后端如何接收和校验这个 Token（以 Express 为例）
Node.js/Express 中，可通过 req.query.token 获取，然后做 JWT 验证或数据库比对。注意：不要在日志中打印完整 Token，避免泄露。
立即学习“Java免费学习笔记（深入）”；
- 务必验证签名、过期时间、签发者等字段
- 建议限制该 Token 的用途（如仅用于 SSE 订阅），避免复用登录 Token 带来风险
- 可结合用户 session 或 connection ID 做连接级限流与绑定
3. 替代方案对比（为什么不用其他方式）
虽然有人尝试用代理、Cookie 或 CORS 配合自定义 header，但实际受限于 EventSource 规范：
-
无法设置请求头：
EventSource不支持 headers 参数（不像fetch） -
Cookie 可行但不推荐主流程：如果已登录且 Cookie 设置了
HttpOnly=false+SameSite=Lax/None，可自动携带，但缺乏灵活性，也不利于多 Token 场景 - 代理中转（如 Nginx）：可在反向代理层从 header 提取并注入 query，适合统一鉴权网关，但增加运维复杂度
4. 安全提醒与最佳实践
把 Token 放 URL 中有潜在风险，务必遵守以下原则：
- Token 必须是短期有效的（例如 5–30 分钟），且一次性或可主动失效
- 全程使用 HTTPS，防止 URL 被中间人截获（HTTP 下 URL 会被明文记录在服务器日志、代理、浏览器历史中）
- 后端应记录并监控异常的 Token 请求频次，防范暴力探测
- 前端在创建
EventSource前检查 Token 是否为空或过期，避免无效连接
