Go语言实现长连接本质是控制底层连接生命周期并配合协议，WebSocket强烈建议用gorilla/websocket而非已归档的golang.org/x/net/websocket，因其支持子协议协商、自动ping/pong、并发读写保护及更健壮的错误处理。
Go 语言本身不内置“长连接”抽象，net/http 的默认行为仍是短连接；所谓“Go 实现长连接”，本质是通过控制底层连接生命周期、复用 http.ResponseWriter 或直接使用 net.Conn，配合协议（如 WebSocket、HTTP/1.1 keep-alive、自定义 TCP 流）达成服务端可主动推送、连接持久化的效果。
WebSocket 连接必须用 gorilla/websocket 或 golang.org/x/net/websocket？
不是必须，但强烈建议用 gorilla/websocket。原生 golang.org/x/net/websocket 已归档、不再维护，且缺少对子协议协商、ping/pong 自动处理、并发读写保护等关键支持。而 gorilla/websocket 提供了 Upgrader、Conn.WriteMessage、SetReadDeadline 等清晰接口，错误处理也更贴近实际部署需求：
-
Upgrader.CheckOrigin必须显式设置，否则浏览器跨域请求会直接 403 -
Conn.SetPongHandler要配Conn.SetPingHandler，否则客户端发 ping 后无响应，连接会被单方面断开 -
WriteMessage不是线程安全的，多个 goroutine 并发调用会 panic，需加锁或用conn.WriteJSON+ channel 序列化发送
HTTP 长轮询（Long Polling）为什么比 WebSocket 更难稳住连接？
因为 HTTP 协议天然无状态，服务端 hold 住 response 时，中间代理（Nginx、CDN、运营商网关）可能在 30–60 秒内主动断连，且不会通知后端。常见现象是客户端收到 502 Bad Gateway 或空响应，但服务端日志里没报错。
- Nginx 默认
proxy_read_timeout是 60s，必须调大，同时配proxy_buffering off和proxy_cache off - 客户端发起 long polling 请求后，必须设
timeout> 服务端最大 hold 时间，否则前端自己先超时重试，造成连接堆积 - 每个 long polling 请求都占一个 HTTP worker 进程/协程，QPS 上千时内存和文件描述符消耗远高于 WebSocket 单连接多消息模式
用 net.Conn 做裸 TCP 长连接，如何避免 read deadlocks？
根本原因是未区分“协议帧边界”和“TCP 流边界”。conn.Read 可能只读到半个消息，也可能一次读到多个完整消息，若业务逻辑假设每次 Read 返回一个完整包，就会卡死。
立即学习“go语言免费学习笔记（深入）”；
- 不要直接
conn.Read(buf)后解析，改用bufio.Reader+ReadBytes('\n')或自定义分隔符，或按头部长度字段ReadFull拆包 - 务必为
conn.SetReadDeadline设置合理值（如 30s），否则网络闪断时 goroutine 永久阻塞 - 关闭连接前，先
conn.CloseWrite()通知对端“我发完了”，再Read直到 EOF，避免半开连接残留
cc-connect 库真能省掉心跳和重连逻辑？
能省掉大部分，但不能完全交出去。cc-connect 把 KeepAlive、ReconnectBackoff、OnConnect/OnDisconnect 封装成可配置项，但它不感知业务层“消息是否送达”。比如你发了一条指令，对方没回 ACK，cc-connect 不知道该重发还是丢弃。
- 它管理的是“连接对象”的存活，不是“消息”的可靠性
- 若业务要求 at-least-once 语义，仍需在上层加消息 ID + 本地存储 + ACK 回执机制
- 它的
OnHealthCheck默认用 TCP 层Write探活，对某些防火墙严格的环境（如企业内网）可能误判，需替换成业务层 ping/pong
真正难的从来不是建立连接，而是让连接在弱网、代理、进程重启、负载漂移中持续有效——这些细节藏在 SetReadDeadline 的数值里，藏在 Nginx 的 proxy_next_upstream 配置里，也藏在你有没有给每个 WriteMessage 加 recover 包裹。
