WebSocket 握手本质是 HTTP/1.1 升级请求，但标准库 golang.org/x/net/websocket（已弃用）和主流 Gorilla WebSocket 均不支持在 Upgrade 响应中直接写入 Set-Cookie；必须通过显式配置响应头实现，且需注意时机与兼容性。
websocket 握手本质是 http/1.1 升级请求，但标准库 `golang.org/x/net/websocket`（已弃用）和主流 gorilla websocket 均不支持在 upgrade 响应中直接写入 `set-cookie`；必须通过显式配置响应头实现，且需注意时机与兼容性。
在 WebSocket 连接建立过程中，客户端发起的是一个带有 Upgrade: websocket 头的 HTTP 请求，服务端需返回状态码 101 Switching Protocols 并携带一系列特定响应头（如 Sec-WebSocket-Accept、Connection: Upgrade 等）。根据 RFC 6455 §4.2.2，额外的响应头（包括 Set-Cookie）是允许且合法的，但关键在于：这些头必须在连接被“劫持”（hijack）并切换为 WebSocket 协议前，由服务端框架正确注入到最终的 101 响应中。
然而，问题代码中使用的 golang.org/x/net/websocket 是一个已归档、不再维护的旧包（自 Go 1.10 起官方明确建议迁移），其 websocket.Server.ServeHTTP 内部会接管 http.ResponseWriter，并在完成握手后立即 hijack 连接——此时调用 http.SetCookie() 已无效，因为响应头早已锁定或被覆盖。
✅ 正确方案：使用 Gorilla WebSocket（推荐）+ 显式 Header 注入
Gorilla WebSocket 的 Upgrader 提供了 CheckOrigin 和 Subprotocols 等钩子，但不直接暴露响应头写入接口。幸运的是，它支持通过 Upgrader.Header 字段（类型为 func(*http.Request) http.Header）动态设置响应头：
package main
import (
"log"
"net/http"
"github.com/gorilla/websocket"
)
var upgrader = websocket.Upgrader{
// 允许同源（生产环境请严格校验 Origin）
CheckOrigin: func(r *http.Request) bool { return true },
// 动态注入 Set-Cookie 到 Upgrade 响应头
Header: func(r *http.Request) http.Header {
header := make(http.Header)
// 构造 Cookie 实例（注意 Secure=true 仅用于 HTTPS）
cookie := &http.Cookie{
Name: "_c_id_",
Value: "abcd",
Path: "/",
HttpOnly: true,
Secure: false, // 开发环境可设 false；生产务必为 true + HTTPS
MaxAge: 3600, // 1 小时有效期
}
header.Set("Set-Cookie", cookie.String())
return header
},
}
func echoHandler(w http.ResponseWriter, r *http.Request) {
conn, err := upgrader.Upgrade(w, r, nil)
if err != nil {
log.Printf("Upgrade error: %v", err)
http.Error(w, "WebSocket upgrade failed", http.StatusBadRequest)
return
}
defer conn.Close()
for {
_, msg, err := conn.ReadMessage()
if err != nil {
log.Printf("Read error: %v", err)
break
}
if err := conn.WriteMessage(websocket.TextMessage, msg); err != nil {
log.Printf("Write error: %v", err)
break
}
}
}
func main() {
http.HandleFunc("/v2", echoHandler)
log.Println("Server starting on :8080")
log.Fatal(http.ListenAndServe(":8080", nil))
}⚠️ 注意事项：
- Upgrader.Header 函数在 Upgrade() 执行前被调用，确保 Set-Cookie 被写入最终的 101 响应；
- cookie.String() 会按 RFC 6265 格式生成完整 Set-Cookie 字符串（含 Path=、HttpOnly 等属性）；
- 若需设置多个 Cookie，可在 Header 函数中多次调用 header.Add("Set-Cookie", cookie1.String()) 和 header.Add("Set-Cookie", cookie2.String())；
- Secure: true 仅在 HTTPS 环境下生效，HTTP 下浏览器会忽略该标记；
- MaxAge 优先级高于 Expires，推荐使用 MaxAge 控制生命周期。
❌ 为什么 http.SetCookie() 在握手 handler 中失效？
因为 Gorilla 的 upgrader.Upgrade() 内部会：
- 验证握手请求；
- 构建并写入标准 WebSocket 响应头（Upgrade, Connection, Sec-WebSocket-Accept 等）；
- 调用 w.(http.Hijacker).Hijack() 获取底层网络连接；
- 此后 http.ResponseWriter 不再可用，任何对 w.Header() 或 http.SetCookie() 的调用均无效（头已发送）。
因此，所有自定义响应头（包括 Set-Cookie）必须在 Upgrade() 调用前通过 Upgrader.Header 注入，而非在 handler 中后期操作。
? 安全提醒
- Cookie 应设置 HttpOnly: true 防止 XSS 窃取；
- 生产环境必须启用 Secure: true 并部署 HTTPS；
- 避免在 Cookie 中存储敏感凭证（如密码、token），推荐仅存 session ID，并在服务端关联验证；
- 若需跨域携带 Cookie，前端 WebSocket 构造函数需配合 credentials: 'include'（仅浏览器支持），且服务端必须响应 Access-Control-Allow-Credentials: true（注意：此时 Access-Control-Allow-Origin 不能为 *）。
综上，WebSocket 握手阶段添加 Set-Cookie 是完全可行的，但必须依托 Gorilla WebSocket 的 Upgrader.Header 机制，在协议升级前精准注入，而非依赖常规 HTTP 响应流程。这是兼顾标准合规性与工程实践的最佳路径。
