JS客户端向带鉴权的Go WebSocket端点发起连接的实现方案

浏览器环境下的原生JavaScript WebSocket API受W3C标准限制，不支持添加自定义请求头，这是浏览器沙箱的安全约束，任何前端代码都无法突破。Postman作为独立桌面客户端不受浏览器规则限制，因此可以自由添加Authorization头完成连接，这是两者行为差异的根本原因。

根据你的部署场景选对应方案即可：

1. 浏览器端场景（最常用） #

不要硬怼自定义头，用WebSocket标准支持的方式传鉴权令牌，后端做少量兼容即可，推荐优先级从高到低：

• Cookie传参（同域场景首选）
  把JWT令牌写入对应域名的Cookie，浏览器发起WS握手请求时会自动携带该域名下的合法Cookie，你现有的Go鉴权中间件只要新增从Cookie读取Bearer令牌的逻辑即可，原有Header读token的逻辑可以保留，改造成本极低。
• Sec-WebSocket-Protocol头传参（跨域场景首选）
  这个头是WS协议标准预留、原生API唯一允许开发者自定义内容的握手头，构造WS实例时把令牌作为子协议参数传入即可，完全不需要引入第三方库：

  // 浏览器原生代码即可实现
  const token = "你的JWT令牌值"
  const ws = new WebSocket("ws://qwerty:1234/api/ws", [`bearer.${token}`])
  

  Go侧需要做两处小改动：
  1. 鉴权中间件新增从Sec-WebSocket-Protocol请求头提取令牌的逻辑
  2. 令牌校验通过后，在WS升级响应中回传相同的子协议值，否则浏览器会主动断开连接，gorilla/ws配置示例：

  // 从请求头拿到客户端传的子协议值
  subProtocol := r.Header.Get("Sec-WebSocket-Protocol")
  upgrader := websocket.Upgrader{
      Subprotocols: []string{subProtocol}, // 回传匹配的子协议
      CheckOrigin: func(r *http.Request) bool { return true }, // 按你的跨域需求配置
      // 其余原有配置保持不变
  }
  

• URL查询参数传参（开发环境临时用）
  直接把令牌拼接到连接URL上：ws://qwerty:1234/api/ws?token=xxx，后端从Query参数提取令牌校验即可。这个方案实现最快，但URL参数会被代理、服务端日志明文记录，存在令牌泄露风险，禁止在生产环境使用。

2. Node.js客户端场景 #

如果你写的是Node端而非浏览器端的WS客户端，可以直接用ws这个npm包，它完全支持自定义请求头，行为和Postman完全一致，服务端不需要做任何改动：

// 仅Node.js环境可用，浏览器环境下该配置无效
import WebSocket from 'ws'
const ws = new WebSocket('ws://qwerty:1234/api/ws', {
  headers: {
    'Authorization': `Bearer ${你的JWT令牌}`
  }
})

注意：所有声称可以在浏览器环境下给WS请求添加自定义头的JS库都是无效的，浏览器底层的网络栈没有开放对应权限，上层JS无法突破这个限制。

3. 无侵入架构方案 #

如果不想修改现有Go服务的鉴权逻辑，可以在WS服务前加一层反向代理，由代理层把Cookie、URL参数中的令牌转换成Authorization请求头再转发给后端服务，业务代码零改动。

• 浏览器环境下无法1:1模拟Postman自定义Authorization头的WS请求行为，受安全限制所限没有可行路径。
• Node.js环境下使用上述ws库的headers配置发出的请求，和Postman发出的请求结构完全一致，服务端无感知差异。

内容的提问来源于stack exchange，提问作者Daniel Chettiar