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

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

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

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

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

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

用 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 执行结束后调用，不能在异步写入尚未完成时抢先读取。

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

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 的内部兼容字段误导。

常见问题

Handler 没有写任何内容时，应该断言哪个状态码？

断言 recorder.Result().StatusCode。它会反映隐式的 200；不要把 recorder.Code == 0 当成真实 HTTP 状态。

为什么响应头断言要放在 Result 之后？

Result().Header 表示响应视图中的头部快照，更接近客户端最终接收到的结果；直接读取 Recorder 的内部字段容易忽略提交时机。

读取响应体后需要关闭 Body 吗？

需要。即使 ResponseRecorder.Result() 返回的是测试响应，也应按 defer resp.Body.Close() 的习惯管理资源。