Go的net/http默认无法支撑10万WebSocket连接，因其每连接一goroutine模型导致内存与文件描述符耗尽，且缺乏限流、心跳、异常驱逐机制。
为什么 net/http 默认无法撑住 10 万 WebSocket 连接
Go 的 http.Server 默认用每个连接一个 goroutine 模型，看似轻量，但百万级连接下，goroutine 调度、内存开销（每个约 2KB 栈）、TCP 连接状态维护（net.Conn + bufio.Reader/Writer）会迅速吃光内存和文件描述符。更关键的是，http.Serve() 内部没有连接限流、心跳复位、异常连接自动驱逐机制，长连接堆积后，新连接 accept 失败、超时、或被内核丢包。
实操建议：
- 必须替换默认
http.Server的ConnState回调，主动跟踪StateNew/StateClosed，做连接数硬限（比如atomic.AddInt64(&connCount, 1) > 100000就直接conn.Close()） - 禁用
http.Server.ReadTimeout和WriteTimeout—— 它们对长连接有害；改用应用层心跳（如每 30sconn.WriteMessage(websocket.PingMessage, nil)）+SetReadDeadline()动态刷新 - 避免在
http.HandlerFunc里直接升级 WebSocket：upgrader.Upgrade()后立即 spawn goroutine 处理读写，否则 handler 返回前连接可能已被客户端断开，导致panic: write tcp: use of closed network connection
gorilla/websocket 升级时最常踩的三个坑
它不是“开箱即用”的高性能方案，很多默认配置直面百万连接就露馅。
常见错误现象：客户端反复重连、服务端日志刷屏 websocket: close sent、CPU 突升但吞吐不涨。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 设置
Upgrader.CheckOrigin = func(r *http.Request) bool { return true }前务必加域名白名单校验，否则 DDoS 攻击可伪造 Origin 耗尽连接数 - 必须调
upgrader.Subprotocols显式声明支持的子协议（如[]string{"v1"}），否则某些 CDN 或代理会静默拦截 Upgrade 请求 -
upgrader.WriteBufferSize和ReadBufferSize别设成 0 —— 默认 4096 太小，高并发消息 burst 时频繁 malloc，建议设为 65536；但也不要盲目设大，超过 OS socket buffer（net.core.wmem_max）会触发阻塞
连接管理不能只靠 map[string]*websocket.Conn
用 map 存连接看着简单，实际在分布式部署、滚动更新、连接异常中断时完全不可靠：key 冲突、goroutine 泄漏、map 并发写 panic、节点宕机后用户状态丢失。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
使用场景：需要支持单点登录踢人、消息离线缓存、跨实例广播（如群聊）。
实操建议：
- 连接元数据（用户 ID、设备 ID、登录时间、IP）必须单独存到带 TTL 的 Redis Hash，键为
conn:{connID}；连接对象本身只保留在内存中，生命周期与 TCP 连接严格一致 - 用
sync.Map存活跃连接映射（userID → connID），但仅作本地快速查找；所有“踢指定用户”操作，先删 Redis，再查sync.Map找到对应connID，最后安全关闭连接（conn.WriteMessage(websocket.CloseMessage, websocket.FormatCloseMessage(websocket.CloseGoingAway, ""))） - 不要依赖
defer conn.Close()清理 —— 必须在readPump和writePump两个 goroutine 都退出后，显式从sync.Map删除并通知 Redis 过期
横向扩展时，WebSocket 连接无法“真正共享”
WebSocket 是有状态的长连接，TCP 层绑定在某个实例上，负载均衡器（如 Nginx、ALB）只能做连接分发，无法把同一个用户的后续请求“导回”原节点 —— 所以广播、私信、状态同步都得走外部通道。
性能影响：如果所有消息都经 Redis Pub/Sub 中转，延迟增加 2–5ms，QPS 上限受限于 Redis 单节点吞吐（通常 5–10w ops/s）。
实操建议：
- Nginx 必须开启
proxy_set_header Upgrade $http_upgrade;和proxy_set_header Connection "upgrade";，否则 WebSocket 握手失败，错误信息是HTTP/1.1 400 Bad Request - 用 Redis Streams 替代 Pub/Sub 做消息总线 —— 支持消费者组、ACK、重放，避免消息丢失；每个服务实例起一个消费者组成员，独立 ACK
- 对低延迟要求高的操作（如打字状态、在线状态），用 Redis Bitmap 或 Sorted Set 做轻量聚合，避免每条状态都走消息队列
真正的难点不在代码怎么写，而在于你得时刻清楚：哪部分状态在内存、哪部分在 Redis、哪部分其实根本没存 —— 连接断了，用户重连时，该从哪恢复上下文，这个逻辑一旦漏掉一环，前端就会卡在“正在连接…”。
