长轮询本质是服务端延迟响应以保持HTTP连接打开，等待数据或超时后才返回；需用context控制超时、避免裸sleep、及时释放资源。
长轮询的本质是 HTTP 连接不立即关闭
长轮询不是特殊协议，只是服务端在没数据时先不写响应、不调用 WriteHeader 或 Write，把连接挂起。客户端发一次请求，服务端卡着不回，直到有数据或超时才响应。关键不在“轮”，而在“长”——连接保持打开状态等待事件。
Go 的 http.ServeMux 和 net/http 默认支持这种阻塞式写法，但要注意：一旦开始写响应（比如调用了 Write），就不能再改状态码或 header；而如果全程不写，连接就一直挂着。
- 必须设置合理的超时，否则连接会无限期等待，耗尽服务器 goroutine 和文件描述符
- 不要在 handler 里直接用
time.Sleep模拟等待——它会阻塞整个 goroutine，但问题不大；真正危险的是忘了设超时或没做 context 取消监听 - 客户端必须支持连接保持（HTTP/1.1 默认 keep-alive），且要处理 504 Gateway Timeout 或连接中断重试逻辑
用 context.WithTimeout 控制单次等待上限
不能靠裸 sleep 等待，得结合 context 实现可取消、可超时的等待。典型做法是：启动一个 goroutine 监听数据源（如 channel），同时用 select 等待数据或 context 超时。
func longPollHandler(w http.ResponseWriter, r *http.Request) {
ctx, cancel := context.WithTimeout(r.Context(), 30*time.Second)
defer cancel()
ch := getDataChannel() // 假设这是你自己的数据通道
select {
case data := <-ch:
w.Header().Set("Content-Type", "application/json")
json.NewEncoder(w).Encode(map[string]string{"data": data})
case <-ctx.Done():
if errors.Is(ctx.Err(), context.DeadlineExceeded) {
w.WriteHeader(http.StatusRequestTimeout)
w.Write([]byte(`{"error":"timeout"}`))
}
}
}
-
context.WithTimeout是必须的，硬编码 sleep 不具备中断能力，goroutine 会卡死直到超时触发 - 别在
select外提前写 header——万一走 timeout 分支，WriteHeader就会 panic - 如果数据源是数据库查询，记得给查询也套上 context，避免后端慢查询拖垮长轮询连接
客户端 JavaScript 怎么发长轮询请求不崩溃
浏览器原生 fetch 默认没有超时控制，且 response body 流式读取容易出错；推荐用 XMLHttpRequest 或封装好的 AbortController + fetch，重点是手动管理连接生命周期。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
- 每次响应后必须立刻发起下一次请求，否则“轮询”就断了——这不是服务端责任，是前端逻辑
- 不要复用同一个
fetch请求对象；每次都要新建，否则可能遇到TypeError: Failed to fetch后无法恢复 - 务必监听
abort事件或检查response.ok，网络中断、服务端重启、Nginx 默认 60s 超时都会导致连接意外关闭 - 示例片段中，
signal: controller.signal和setTimeout(() => controller.abort(), 35000)要配对，客户端超时略大于服务端（比如服务端 30s，前端设 35s），留出网络延迟余量
为什么用 channel 而不是全局变量或锁来通知数据
channel 是 Go 中最自然的跨 goroutine 事件通知机制。长轮询 handler 是并发执行的，每个请求对应一个 goroutine，数据到来时需精准唤醒对应等待者，而非广播给所有人。
- 用
map[requestID]chan string+ 定时清理，比用sync.Mutex+ 切片遍历更轻量、无竞争 - 不要用
time.AfterFunc去“定时推送”，它无法绑定到某个具体请求的生命周期，容易造成 goroutine 泄漏 - 如果数据源来自外部（如 Kafka、Redis Pub/Sub），建议用单独 goroutine 拉取并转发到各等待 channel，避免在 handler 里直连外部服务
- 注意 channel 容量：用
make(chan string, 1)防止发送方阻塞；若允许多条积压，容量设为 1 即可，长轮询本意就是“一次响应一条”
真正难的不是怎么挂起连接，而是怎么安全地把数据从任意 goroutine 推送到正在等待的那个 handler goroutine 里——channel 是唯一简洁可靠的解法。其他方式要么漏通知，要么多通知，要么死锁。
