Go 实现长轮询的完整方案

本文深入剖析了在 Go 中实现长轮询的常见误区与正确实践，指出直接在 HTTP handler 中使用无限循环或长时间 Sleep 会导致 goroutine 阻塞、并发耗尽及连接断开后资源泄漏等严重问题；强调必须禁用默认读写超时、结合 context 可取消机制、select 多路复用与定时器（time.After）构建安全的三重控制逻辑，并通过事件驱动方式（如全局 channel 注册+监听）替代被动等待，同时给出 sync.Map 或锁保护、channel 关闭时机等关键细节，帮助开发者写出高可靠、低泄漏、可扩展的长轮询服务。

长轮询为什么不能直接用 http.HandleFunc 配合无限循环

Go 的 HTTP handler 默认是短连接、同步阻塞模型，一旦在 handler 里写 for {} 或长时间 time.Sleep，会卡死 goroutine，耗尽服务器并发能力。更关键的是，客户端（尤其是浏览器）可能在 30–60 秒后主动断开连接，而 Go 默认的 http.Server 并不会自动清理已断开但 handler 还在跑的 goroutine，导致资源泄漏。

实操建议：

• 必须设置 http.Server.ReadTimeout 和 WriteTimeout，防止连接僵死
• 每个长轮询请求要绑定一个可取消的 context.Context，并在连接断开时触发 cancel
• 避免在 handler 内部做无界等待；改用带超时的 channel select + ctx.Done() 检测

net/http 中如何安全地等待事件并响应

核心不是“等”，而是“注册监听 + 事件驱动响应”。典型做法是用一个全局的 map[string]chan interface{} 存放各客户端的事件通道，handler 启动后立即把当前 goroutine 的 channel 注册进去，然后阻塞在 select 上，等待事件或上下文取消。

常见错误现象：panic: send on closed channel —— 客户端断开后没及时关闭 channel，后续事件仍往里发。

实操建议：

• 注册 channel 时用 sync.Map 或加读写锁，避免并发写 panic
• 每次向 channel 发送前，先用 select { case ch 非阻塞尝试，失败则说明 client 已掉线
• 不要用 close(ch) 清理 channel，而是用 delete() 从 map 中移除，并让 goroutine 自然退出

select {
case ch := <-registerCh:
    select {
    case ch <- data:
    default:
        // client gone, skip
    }
case <-time.After(5 * time.Second):
    // timeout, no one listening
}

客户端断连后服务端怎么及时感知并清理

HTTP/1.1 下，服务端无法主动探测客户端是否还活着。依赖 ResponseWriter 的底层连接状态是不可靠的——即使 Write 成功，也不代表客户端收到了数据。

真正有效的判断方式只有两种：客户端主动发心跳（不推荐，增加复杂度），或利用 http.CloseNotifier（已废弃）的替代方案：Request.Context().Done()。

实操建议：

• 所有长轮询 handler 必须以 if err := req.Context().Err(); err != nil { return } 开头，第一时间检查上下文是否已取消
• 不要依赖 defer func() { close(ch) }()，因为 defer 在函数 return 后才执行，而 handler 可能被强制中断
• 用 http.TimeoutHandler 包裹 handler 是个保险做法，但它会在超时后直接返回 503，不适用于需要自定义超时响应的场景

要不要用 gorilla/websocket 替代长轮询

如果业务允许升级协议，WebSocket 几乎总是比长轮询更优：连接复用、低延迟、双向通信、服务端可主动推。但要注意真实约束：

实操建议：

• CDN 或反向代理（如 Nginx）默认不透传 WebSocket 升级头，需显式配置 proxy_set_header Upgrade $http_upgrade; 等三行
• 某些企业防火墙或老旧网络设备会拦截非 80/443 的 WebSocket 连接，长轮询反而更“兼容”
• 若只是单向推送（如日志流、通知），且客户端只支持 fetch，那硬上 WebSocket 反而要额外写降级逻辑

长轮询真正的复杂点不在代码长度，而在连接生命周期管理——什么时候注册、什么时候注销、事件来了发给谁、发失败了怎么兜底。这些细节漏掉一个，压测时就容易出现 goroutine 泄漏或消息丢失。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于Golang的相关知识，也可关注golang学习网公众号。