WebSocket握手时Cookie不可直接用c.Cookie()获取，因Echo的c.Cookie()依赖已消费的*http.Request，可靠方式是手动解析r.Header.Get("Cookie")字符串并用http.ParseCookies解析，在Upgrader.CheckOrigin中完成校验。
WebSocket握手时Cookie不可直接用c.Cookie()获取
因为Echo的c.Cookie()底层依赖http.Request.Cookies，而标准http.Handler在升级为WebSocket连接后，原始*http.Request已被消费，部分字段（如Header）仍可读，但Cookies()方法可能返回空或panic——尤其当请求头中Cookie字段被中间件修改、或使用了某些代理时。
真正可靠的方式是手动解析Cookie请求头：
-
c.Request().Header.Get("Cookie")始终可用，返回原始字符串（如"session_id=abc123; theme=dark"） - 用
http.ParseCookie或http.ParseCookies解析，注意它不自动处理Secure/HttpOnly等属性，只做键值提取 - 若需校验签名或解密，必须在解析后单独处理，Echo不介入WebSocket握手后的Cookie生命周期
用echo.WrapHandler配合gorilla/websocket更可控
原生Echo的WebSocket支持较弱，推荐用gorilla/websocket手写升级逻辑，再用echo.WrapHandler接入。这样可在Upgrader.CheckOrigin或自定义handshake函数里自由读取Cookie头：
upgrader := websocket.Upgrader{
CheckOrigin: func(r *http.Request) bool {
cookieStr := r.Header.Get("Cookie")
// 解析并验证 session_id
cookies, _ := http.ParseCookies([]byte(cookieStr))
for _, ck := range cookies {
if ck.Name == "session_id" {
// 校验逻辑：查DB、验签名、检查过期...
return isValidSession(ck.Value)
}
}
return false
},
}
注意：CheckOrigin必须返回true才允许升级，这里就是读取和校验Cookie的黄金位置。
避免在WebSocket handler里重复解析Cookie
一旦连接升级成功，后续所有ws.ReadMessage()收发都与HTTP无关，echo.Context对象已失效。常见错误是试图在ws.OnMessage回调里调用c.Cookie()——这会panic或返回nil，因为c此时不再绑定有效请求。
- 所有认证/用户信息必须在握手阶段完成，并通过
conn或闭包传入WebSocket消息处理器 - 例如：在
CheckOrigin中解析出userID，存入context.WithValue，再用upgrader.Upgrade的http.ResponseWriter参数间接传递（实际常用map缓存+conn ID索引） - 不要依赖Echo中间件对WebSocket连接生效——它们只作用于HTTP阶段
跨域场景下浏览器可能不带Cookie头
如果前端WebSocket连接地址与主站不同源（比如ws://localhost:8080连https://app.example.com），默认不会发送Cookie，即使设置了withCredentials: true，后端也收不到。
- 确保前端创建
WebSocket时显式启用凭证：new WebSocket(url, { withCredentials: true })（注意：不是所有浏览器都支持第二个参数，稳妥做法是服务端配置CORS +Access-Control-Allow-Credentials: true） - 服务端
Upgrader需设置CheckOrigin宽松匹配，且响应头中必须含Access-Control-Allow-Credentials: true，否则浏览器静默丢弃Cookie - 若用Nginx反向代理，确认未过滤
Cookie头：proxy_pass_request_headers on;，并透传Origin
真正难调试的是“看起来没报错，但Cookie头就是为空”——八成卡在跨域凭据或代理配置上。
