golang长连怎么用

说个常识啊，Go 里头搞“长连接”，可不是调个参数就能万事大吉的。你得先想清楚，你到底用的是哪一类的长连接：是 HTTP 长轮询、WebSocket，还是裸 TCP？这三个玩意儿的底层逻辑差别很大，配置混着用，那基本等于白忙活一场。

HTTP 长轮询：别在 Transport 的 MaxIdleConnsPerHost 上白费力气

我见过不少朋友，一上手就去调 http.Transport.MaxIdleConnsPerHost 或者 IdleConnTimeout，结果发现客户端还在频繁重连。为啥？因为长轮询根本不靠复用连接活着，它玩的就是“单个请求挂住，服务端不返回”。

• 服务端这边，你得显式调用 w.WriteHeader(http.StatusOK) 再加上 w.(http.Flusher).Flush()。不然客户端收不到响应头，就会一直卡在 CONNECTING 状态动弹不得。
• Nginx 默认的 proxy_read_timeout 只有 60 秒，超时就直接把连接给掐断了。所以，必须把这个值调大，比如设置为 300 秒。
• 客户端的情况更典型：不能用 http.Client.Timeout 来控制整体耗时，因为响应头一发出去，这个超时就不管用了。正确的做法是用 context.WithTimeout 来构造 request，然后在读 body 之前，先检查一下 ctx.Err()。
• 还有，json.NewDecoder(resp.Body).Decode() 这个操作本身是不感知 context 的。一旦服务端不把数据写完，它就会一直等下去。要么用 io.ReadFull，要么自己手动分段读，顺便检查 ctx，这才是稳妥的办法。

WebSocket：别让每个连接都背上一个定时器

如果你用的是 gorilla/websocket，它的默认心跳和定时器在百万连接数下会是一个大坑——runtime.timer 会直接把 CPU 吃光。

• 首要操作是禁用默认心跳：conn.SetPongHandler(nil)。然后自己用 time.Ticker 来批量轮询那些活跃的连接状态。
• 把 ReadBufferSize 和 WriteBufferSize 降到 1024 和 512，够用，还能省下不少内存。
• 内网环境如果可信，Upgrader.CheckOrigin 直接返回 true 就完事了，省掉一次字符串比较的开销。
• 连接 ID 也别用 string 当 map key 了，换成 uint64，能有效避免哈希和 GC 的压力。

TCP 长连接：超时控制得分开看，读和写是两码事

只设一个 SetKeepAlive(true) 基本没啥用，NAT 或者中间设备照样会把你的连接断掉。真正要关注的，是业务层面能感知到的“活跃”状态。

• 服务端得对每个 net.Conn 都调用 conn.SetReadDeadline 和 conn.SetWriteDeadline。时间设置上，要稍微大于心跳间隔（比如心跳 30 秒，deadline 设成 45 秒）。
• 客户端发心跳的时候，别只靠一个 conn.Write 就完事了。你得启动一个独立的 goroutine 去读响应，一旦报错立刻重连。
• 重连策略必须用指数退避（1秒 → 2秒 → 4秒……），上限建议设在 30 秒，避免高并发场景下出现雪崩。
• 粘包问题也必须处理。推荐使用定长头方案：前 4 个字节存 body 长度，读取的时候用 io.ReadFull 保证拿到的是完整的一帧数据。

连接管理：map 并发写导致的 panic，是高频翻车现场

很多新手直接拿 *net.Conn 往 map[string]*net.Conn 里存，跑起来必 panic，错误信息就是那句经典的 “concurrent map read and map write”。

• 正确的做法是用 map[uint64]*ConnMeta 加上 sync.RWMutex。在读多写少的场景下，性能损失很小。
• ConnMeta 结构体里，得嵌一个 sync.Once 和 atomic.Bool，防止多个 goroutine 同时去 close 同一个连接，搞出死锁或者重复关闭来。
• 千万注意：不要在 conn.Read() 的那个 goroutine 里直接 delete(m, id)，要通过发信号的方式，交给一个统一的清理协程去处理。
• 定期扫描连接池（比如每 30 秒一次），把那些 LastPingTime.Add(2 * heartbeatInterval).Before(time.Now()) 的连接清理掉。

老实说，这里头最容易忽视的问题是错误归因。很多人一看连接断了，第一反应不是去查 conn.Read 返回的 io.EOF 或者 net.OpError，而是跑去调 Transport 的参数。方向完全搞反了，只会越调越糟糕。