当前位置：首页 > 文章列表 > Golang > Go教程 > Go 怎么用 httptest.ResponseRecorder 检查响应头和写入状态

Go 怎么用 httptest.ResponseRecorder 检查响应头和写入状态

来源：17golang原创 2026-09-07 13:14:18 0浏览收藏

测试 Go 的 HTTP Handler 时，不必先启动端口。httptest.NewRecorder() 会记录 Handler 对 http.ResponseWriter 的写入，测试结束后用 Result() 还原成一份可读的 http.Response。这样，响应状态、头部和正文可以分别断言，失败时也更容易知道是哪一层出了问题。

要点速览

状态码看 Result().StatusCode，响应头看 Result().Header，正文从 Result().Body 读取。
ResponseRecorder.Code 在 Handler 没有写任何内容时可能还是 0，不等于最终隐式状态码 200。
响应头要在第一次 WriteHeader 或 Write 前设置；HeaderMap 已不适合作为最终响应断言入口。

先把状态码、响应头和响应体分成三条断言

一个 Handler 的输出其实有三层：状态码说明请求结果，响应头说明元数据，响应体承载业务内容。把三层混在一个字符串比较里，通常只能发现“内容不对”，不能定位是状态码没写、头部写晚了，还是 JSON 序列化出了问题。

ResponseRecorder 的静态关系可以先这样理解：Handler 只面对 ResponseWriter，Recorder 保存写入痕迹，Result() 再把痕迹转换成测试用的 Response，断言代码只读取 Response。

Go httptest ResponseRecorder 中 Handler、ResponseWriter、Result 和三类响应断言的静态关系 — 图1：把 Handler 的写入动作分到状态码、响应头和响应体三条断言路径，便于定位测试失败层次。

因此，测试设计可以先列出一个小表：

要验证的结果	推荐读取位置	关注点
状态码	`resp.StatusCode`	显式状态与默认 200
响应头	`resp.Header.Get(...)`	键名、值和写入时机
响应体	`io.ReadAll(resp.Body)`	正文内容与读取错误

用 NewRecorder 和 NewRequest 构造可重复的 Handler 测试

下面的 Handler 模拟一个创建接口：先设置 JSON 头，再写出 201，最后输出一段正文。测试不依赖网络端口，失败时能直接看到响应的三部分。

func TestCreateHandler(t *testing.T) {
    handler := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        // 头部必须放在第一次写入响应之前。
        w.Header().Set("Content-Type", "application/json")
        w.WriteHeader(http.StatusCreated)
        // 正文只表达本测试需要验证的最小结果。
        _, _ = io.WriteString(w, `{"id":42,"state":"created"}`)
    })

    // NewRequest 生成适合传给服务端 Handler 的请求对象。
    req := httptest.NewRequest(http.MethodPost, "/items", nil)
    recorder := httptest.NewRecorder()
    handler.ServeHTTP(recorder, req)

    // Result 必须在 Handler 完成后调用，并把 Body 交给调用方关闭。
    resp := recorder.Result()
    defer resp.Body.Close()
    body, err := io.ReadAll(resp.Body)
    if err != nil {
        t.Fatalf("读取响应体失败: %v", err)
    }
    if resp.StatusCode != http.StatusCreated {
        t.Fatalf("状态码 = %d, want %d", resp.StatusCode, http.StatusCreated)
    }
    if got := resp.Header.Get("Content-Type"); got != "application/json" {
        t.Fatalf("Content-Type = %q", got)
    }
    if string(body) != `{"id":42,"state":"created"}` {
        t.Fatalf("响应体 = %s", body)
    }
}

这里的关键不是把断言写得更长，而是让每条断言只负责一个事实。后续如果接口改成 202，状态码断言会先提示契约变化；如果 JSON 内容变化，响应体断言才会失败。

为什么应该用 Result 而不是直接读 Code 或 HeaderMap

ResponseRecorder.Code 记录的是 Handler 显式调用 WriteHeader 后的值。若 Handler 什么都没有写，它可能是 0；HTTP 响应语义里的隐式 200 要通过 Result().StatusCode 查看。类似地，官方文档把 HeaderMap 标为历史兼容字段，最终返回给客户端的头部应从 Result().Header 读取。

Result() 还会提供非空的 Body，并保证读取时除了 io.EOF 外不会返回其他读取错误。不过它只能在 Handler 执行结束后调用，不能在异步写入尚未完成时抢先读取。

Go ResponseRecorder 的 Code、HeaderMap、Body 与 Result 返回 Response 之间的边界关系 — 图2：区分 Recorder 的内部记录字段和 Result 返回的最终响应视图，避免用历史字段代替客户端可见结果。

常见误区：写入顺序会改变你看到的响应头

HTTP 响应的头部不是可以无限晚写的。Handler 一旦调用 WriteHeader，或者在没有显式状态码时第一次调用 Write，响应头就进入提交边界。此后再执行 w.Header().Set，通常不会改变已经被 Recorder 记录的那份响应头。

另一个容易忽略的点是状态码只能以第一次写入为准。下面这种写法看似想把 200 改成 500，测试却会拿到第一次提交的状态：

func handler(w http.ResponseWriter, r *http.Request) {
    // 第一次提交已经确定响应状态和头部快照。
    w.WriteHeader(http.StatusOK)
    // 后续状态码不会覆盖已经提交的 200。
    w.WriteHeader(http.StatusInternalServerError)
}

排查这类问题时，先把 Header 的设置集中到写入前，再只保留一次明确的 WriteHeader。测试中优先断言 Result()，既贴近调用方看到的响应，也不会被 Recorder 的内部兼容字段误导。