go长轮询中http.client.timeout不生效，因服务端流式写入会重置计时器；应改用responseheadertimeout+context.withtimeout控制读取，且需透传context至所有i/o操作。
Go 长轮询测试中 http.Client 超时设置不生效？
根本原因不是代码没写超时，而是长轮询本身会“吃掉”你设的 Timeout。Go 的 http.Client.Timeout 是整个请求生命周期上限（含连接、读写），但长轮询在服务端迟迟不返回响应体，客户端卡在 Read 阶段，此时 Timeout 确实会触发——可一旦服务端开始流式写入（哪怕只写一个字节），计时器就重置了。结果就是：你以为 5 秒超时，实际等了 30 秒才断。
真正该用的是 http.Client 的细粒度超时控制：
-
Timeout放弃，它对长轮询不可靠 - 改用
Transport的ResponseHeaderTimeout：限制从连接建立到收到响应头的时间（防服务端连 header 都不发） - 再配合
Transport的IdleConnTimeout和KeepAlive，避免连接池干扰测试 - 最终读取响应体时，用
context.WithTimeout包裹resp.Body.Read操作，这才是对“等待数据”的精准超时
用 httptest.Server 模拟长轮询服务时，time.Sleep 不是万能解
本地测试里直接 time.Sleep(10 * time.Second) 再写响应，看似模拟了长轮询，但会掩盖真实并发问题：比如客户端是否真的在等，还是提前 panic；服务端是否正确保持连接，还是被中间件（如反向代理、负载均衡）悄悄断开。
更贴近生产环境的做法是分阶段控制响应流：
立即学习“go语言免费学习笔记（深入）”；
- 先写状态码和 header（
w.WriteHeader(http.StatusOK)），确保连接已建立 - 调用
w.(http.Flusher).Flush()强制刷出 header，让客户端明确进入“等待 body”状态 - 再用
time.AfterFunc或 goroutine 延迟写入 body 内容，模拟服务端条件触发 - 务必在 handler 里 defer
resp.Body.Close()，否则httptest的连接不会释放，后续测试可能卡死
异步超时判定失败，大概率是 context 没传到最底层
长轮询测试里常见错误：外层用 context.WithTimeout 启动 goroutine，但没把 context 透传给 http.NewRequestWithContext，或者忘了在 io.Copy / json.Decoder.Decode 这类阻塞读操作中检查 ctx.Err()。
关键点就两个：
- 所有阻塞 I/O 必须基于带 context 的 reader/writer，例如用
http.NewRequestWithContext(ctx, ...)，而不是http.NewRequest(...) - 手动读 body 时，别用
body.Read(buf)，改用io.ReadFull(ctx.Done(), body, buf)或封装一个带 cancel 检查的循环读函数 - 如果用了
json.NewDecoder(body).Decode(&v)，它内部不感知 context —— 必须在外层加select { case 定期检查
测试并发长轮询时，net/http 默认 Transport 会复用连接导致误判
多个测试 goroutine 共享同一个 http.Client，而它的默认 Transport 会复用底层 TCP 连接。当一个请求因超时被 cancel，连接可能被标记为“可复用”，但另一请求复用它时，会继承前一个请求残留的状态（比如半关闭、缓冲区脏数据），导致读取到意外内容或立即 EOF。
解决方法很简单，但容易被忽略：
- 每个测试用例单独 new 一个
http.Client，并配置独立的Transport -
Transport中显式禁用连接复用：MaxIdleConns: 0, MaxIdleConnsPerHost: 0 - 或者更彻底：测试结束后调用
transport.CloseIdleConnections()，防止连接泄漏影响后续测试
长轮询的测试难点不在逻辑，而在连接状态和超时边界的精确控制——漏掉任意一个 context 传递点，或复用了一个本该隔离的连接，结果就不可信。
