HTTP测试：模拟延迟与超时技巧详解

本文深入解析了Go语言中HTTP超时测试的关键实践与常见误区，强调必须使用`httptest.NewUnstartedServer`手动注入可控延迟（如`time.Sleep`）来真实触发客户端超时逻辑，而非依赖无法模拟慢响应的`httptest.NewServer`；指出`http.Client.Timeout`才是保障全生命周期超时的唯一可靠配置，需配合`errors.Is(err, context.DeadlineExceeded)`精准断言超时错误，避免误判其他网络异常；同时揭示并发测试中handler串行执行导致的延迟失真问题，并提供goroutine分发、独立server实例或同步原语等方案，确保测试行为与生产环境一致——掌握这些细节，才能让HTTP超时测试真正成为系统韧性的可靠防线。

用 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 才管“整个请求生命周期”，包括发完请求后等响应的时间。

• Client.Timeout 是总开关，设为 1 * time.Second 就意味着从 Do 开始计时，1 秒内没拿到完整响应就报 context.DeadlineExceeded
• 单独设 Transport 的 DialTimeout 或 ResponseHeaderTimeout 只覆盖局部阶段，容易漏掉读 body 超时
• 如果 handler 里 WriteHeader 很快但 Write body 拖很久（比如流式大文件），还得额外设 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 中途。这些细节一错，测试就和线上行为对不上。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《HTTP测试：模拟延迟与超时技巧详解》文章吧，也可关注golang学习网公众号了解相关技术文章。