长轮询不能直接用http.HandleFunc配合无限循环，因HTTP handler默认同步阻塞，for{}或time.Sleep会卡死goroutine、耗尽并发能力，且客户端超时断开后Go不自动清理goroutine导致泄漏；须禁用读写超时，用context、select和time.After实现三重控制并defer清理资源。
长轮询为什么不能直接用 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 泄漏或消息丢失。
