gorilla/websocket服务扛不住因默认配置不合理：checkorigin返回false阻塞握手，读写缓冲区仅4096字节致cpu飙升；需显式配置checkorigin、增大缓冲区、禁用压缩；nginx需正确配置proxy_http_version、upgrade头及超时；平滑迁移靠sigusr2信号draining与redis暂存消息；k8s中应使用headless service或ingress实现客户端重连。
WebSocket 连接数暴涨时，gorilla/websocket 服务为啥扛不住？
不是代码写错了，而是默认配置把连接压垮了——gorilla/websocket 的 Upgrader.CheckOrigin 默认返回 false，看似安全，实则在高并发握手阶段直接阻塞；更隐蔽的是 WriteBufferSize 和 ReadBufferSize 默认只有 4096 字节，小包多、心跳密的场景下，频繁系统调用 + 内存拷贝会吃掉大量 CPU。
- 生产环境必须显式设置
Upgrader.CheckOrigin = func(r *http.Request) bool { return true }（或按需校验），否则每秒几百次握手就卡住 -
WriteBufferSize建议设为64 * 1024，避免小消息触发多次Write()底层 syscall - 禁用
Upgrader.EnableCompression = true—— WebSocket 压缩在长连接高频通信中反而因加解压拖慢吞吐，实测延迟上升 20%~40%
单机撑不住了，为什么不能直接用 Nginx 做 WebSocket 负载均衡？
Nginx 确实能转发 Upgrade: websocket 请求，但默认不透传连接生命周期事件，导致后端服务收不到断连通知，conn.Close() 不触发，连接泄漏；更关键的是，Nginx 的 proxy_buffering off 必须配对 proxy_http_version 1.1 和 proxy_set_header Upgrade $http_upgrade，漏一条，连接就会在 60 秒后被静默关闭。
- 务必在 location 块里加：
proxy_read_timeout 3600（别信默认 60 秒） - 确认 Nginx 版本 ≥ 1.13.12，旧版本对
Connection: upgrade处理有竞态 bug - 用
ss -s | grep "tw"观察 TIME_WAIT 连接是否堆积——如果是，说明 Nginx 没正确复用后端连接，要加proxy_http_version 1.1+proxy_set_header Connection ''
如何让新老连接平滑迁移，不丢消息？
扩容时最怕用户正在发弹幕、传实时坐标，一重启就断——Golang 本身没内置热重载，但可以靠信号 + 连接 draining 实现“软下线”。核心是：收到 SIGUSR2 后停止接受新连接，等现有连接空闲或超时再退出，同时用 Redis Pub/Sub 把未确认消息暂存，新进程启动后拉取。
- 监听信号用
signal.Notify(c, syscall.SIGUSR2)，别用SIGTERM——K8s 默认发这个，容易和 OOM kill 混淆 - draining 时间建议设为 30 秒：
srv.Shutdown(context.WithTimeout(ctx, 30*time.Second))，太短丢连接，太长影响发布节奏 - 消息暂存键名用
ws:pending:<code>pid，避免多个旧进程写冲突
K8s 里 Pod IP 变来变去，客户端怎么维持重连？
客户端不能硬编码 Pod IP，但也不能只靠 Service ClusterIP——它不支持连接保持，且 K8s Service 的 sessionAffinity 默认是 None。真正可行的是：用 Headless Service + DNS SRV 记录查到所有 Pod 的端口，客户端自己做连接池和故障转移；或者更简单，走 Ingress 并开启 sessionAffinity: cookie（需 Ingress Controller 支持 WebSocket）。
立即学习“go语言免费学习笔记（深入）”；
- Headless Service 必须带
publishNotReadyAddresses: true，否则新 Pod 还在 readinessProbe 中时，DNS 就查不到它 - 客户端重连间隔要用指数退避：
time.Second * time.Duration(1，避免雪崩式重连打爆新节点 - 别依赖
kube-proxy的 IPVS 模式做会话亲和——它只对 TCP 连接生效，WebSocket 升级后仍是 HTTP 长连接，亲和性失效
真正的难点不在代码，而在连接状态的可观测性：你得知道每个连接背后的真实用户、所在 Pod、已存活时间、最近一次读写时间——这些信息不埋点，扩容决策就是拍脑袋。别省那几行 prometheus.Counter 和 context.WithValue。
