WebSocket连接建立后立刻断开，因http.ServeMux不支持Upgrade协议升级，需用gorilla/websocket等库并确保路由绕过篡改header的中间件。
WebSocket 连接建立后立刻断开？检查 http.Handler 是否覆盖了升级逻辑
Go 标准库的 http.ServeMux 不支持 WebSocket 协议升级，直接注册 http.HandlerFunc 会返回 400 或静默关闭连接。根本原因是 WebSocket 握手需要处理 Upgrade 请求头、校验 Sec-WebSocket-Key，而普通 handler 会把这当成非法请求。
实操建议：
- 用
gorilla/websocket（最稳）或gobwas/ws（轻量），别自己解析握手 - 确保路由不经过中间件（比如日志、CORS）——它们可能篡改 header 或提前写 response
- 启动服务时加一句
log.Printf("ws server listening on :8080")，确认监听的是 HTTP 服务端口，不是单独起一个 ws 端口（Go 里没有“WS 专用端口”这回事）
var upgrader = websocket.Upgrader{
CheckOrigin: func(r *http.Request) bool { return true }, // 生产需校验 origin
}
func handleWS(w http.ResponseWriter, r *http.Request) {
conn, err := upgrader.Upgrade(w, r, nil)
if err != nil {
log.Println("upgrade error:", err) // 别只写 http.Error，掩盖真实原因
return
}
defer conn.Close()
// 后续读写...
}用 SSE 推送时浏览器收不到数据？确认 Content-Type 和 flush 时机
SSE 要求响应头必须是 text/event-stream，且每次发送事件后必须显式 flush，否则数据卡在 Go 的 http.ResponseWriter 缓冲区里，浏览器永远等不到换行符（\n\n）。
常见错误现象：curl 看到响应头但无 body；Chrome DevTools Network 面板显示 pending；前端 EventSource 一直触发 open 但不触发 message。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 设置
w.Header().Set("Content-Type", "text/event-stream")和w.Header().Set("Cache-Control", "no-cache") - 用
fl := w.(http.Flusher)类型断言后调用fl.Flush()，标准库ResponseWriter在支持流式响应的服务器（如 net/http 默认）才实现该接口 - 每条消息末尾必须有
\n\n，单条消息可拆成data: ...\n\n或event: xxx\ndata: ...\n\n
func handleSSE(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Content-Type", "text/event-stream")
w.Header().Set("Cache-Control", "no-cache")
w.Header().Set("Connection", "keep-alive")
<pre class='brush:php;toolbar:false;'>fl := w.(http.Flusher)
for _, msg := range []string{"hello", "world"} {
fmt.Fprintf(w, "data: %s\n\n", msg)
fl.Flush() // 关键：不 flush 就没输出
time.Sleep(1 * time.Second)
}}
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
推送服务扛不住并发连接？别让每个 WebSocket 连接独占 goroutine 读+写
默认写法是 go conn.ReadMessage() + go conn.WriteMessage()，看似解耦，实际导致大量 goroutine 阻塞在 Read（等待客户端发包）或 Write（网络慢/客户端卡住）。1000 连接 ≈ 2000+ goroutine，内存和调度开销飙升，还容易触发 write: broken pipe。
性能影响明显：QPS 下降、GC 频繁、连接延迟升高。
实操建议：
- 每个连接只启 1 个 goroutine 处理读，把消息发到 channel；另用 1 个 goroutine 从 channel 拉取并广播（或定向写）
- 写操作统一走 channel + select 超时，避免死等；对单个连接写失败时，关掉对应 reader goroutine 和 channel
- 用
conn.SetWriteDeadline()防止长阻塞，错误时直接conn.Close()
业务事件怎么推给指定用户？别在 WebSocket 里裸存 map[string]*websocket.Conn
按用户 ID 做映射看起来直观，但极易引发并发 panic：多个 goroutine 同时读写 map，且 *websocket.Conn 本身不是线程安全的。更麻烦的是，用户登出、token 过期、多端登录时，这个 map 很难及时清理，造成内存泄漏和误推。
使用场景：订单状态变更只通知下单人；客服消息只推给当前会话客户。
实操建议：
- 用
sync.Map存userID → []chan Message，每个连接绑定独立 channel，写消息时遍历 channel 发送，不碰 conn 对象 - 登录成功后生成唯一 sessionID，用它做 map key；登出或心跳超时时，从 map 中删掉对应 channel
- 推送前先检查 channel 是否已 close（用
select { case ），避免 panic
复杂点在于：channel 生命周期管理比 conn 更难跟踪。容易被忽略的是，客户端断网重连时，旧 channel 可能还在 map 里挂着，得靠心跳或 JWT 过期时间兜底清理。
