正确测试http超时需用httptest.newunstartedserver并手动注入延迟，配合显式设置client.timeout，断言时用errors.is(err, context.deadlineexceeded)，并发场景需避免handler串行阻塞。
用 httptest.NewServer 无法测超时，得换 httptest.NewUnstartedServer
因为 httptest.NewServer 启动的是真实监听的 HTTP server，它响应快、无延迟，根本触发不了客户端超时逻辑。真要测超时，必须自己控制 handler 的响应时机。
正确做法是用 httptest.NewUnstartedServer 拿到 server 实例后，手动改它的 Handler，在 handler 里加 time.Sleep 模拟慢响应：
server := httptest.NewUnstartedServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
time.Sleep(3 * time.Second) // 故意拖慢
w.WriteHeader(http.StatusOK)
w.Write([]byte("ok"))
}))
server.Start()
defer server.Close()这样你才能用带 Timeout 的 http.Client 去验证是否真能中断请求。
客户端必须显式设置 Timeout，不能只靠 net.DialTimeout
很多人以为设置了 Transport.DialContext 的拨号超时就完事了，其实不够。HTTP 超时分三段：拨号、写请求、读响应。只有 http.Client.Timeout 才管“整个请求生命周期”，包括发完请求后等响应的时间。
立即学习“go语言免费学习笔记（深入）”；
-
Client.Timeout是总开关，设为1 * time.Second就意味着从Do开始计时，1 秒内没拿到完整响应就报context.DeadlineExceeded - 单独设
Transport的DialTimeout或ResponseHeaderTimeout只覆盖局部阶段，容易漏掉读 body 超时 - 如果 handler 里
WriteHeader很快但Writebody 拖很久（比如流式大文件），还得额外设Transport.ReadTimeout
测试断言要检查错误类型，别只看 err != nil
超时错误不是普通 error，它是 net/url.Error 包裹的 context.DeadlineExceeded。直接判 err != nil 会把连接拒绝、DNS 失败等其他错误也当成超时，导致误判。
正确断言方式：
resp, err := client.Do(req)
if err != nil {
var urlErr *url.Error
if errors.As(err, &urlErr) && errors.Is(urlErr.Err, context.DeadlineExceeded) {
// ✅ 确实是超时
} else {
// ❌ 其他网络错误
}
}注意：errors.Is 比 strings.Contains(err.Error(), "timeout") 可靠得多，后者在 Go 1.20+ 的错误包装机制下会失效。
并发压测时，httptest.Server 默认不支持高并发延迟模拟
httptest.NewUnstartedServer 启动的 server 默认用 http.DefaultServeMux，handler 是串行执行的。如果你开 10 个 goroutine 同时请求并 sleep 2 秒，它们会排队等，总耗时变成 20 秒，而不是预期的 2 秒全部超时。
解决方法是让 handler 并发执行：
- 用
http.ServeMux不够，得自己写 handler，内部用 goroutine 分发 - 或者更简单：每个测试 case 单独起一个
NewUnstartedServer，避免干扰 - 如果真要模拟并发阻塞，handler 里用
sync.WaitGroup或 channel 控制释放时机，比单纯time.Sleep更可控
真正难的不是加 delay，而是让 delay 表现得像真实服务——比如只卡在 read header 阶段，或卡在 write body 中途。这些细节一错，测试就和线上行为对不上。
