Go recorder 怎么处理响应状态

用 Go 测试 HTTP handler 时，httptest.NewRecorder() 返回的 recorder 既能快速查看写入结果，也能通过 Result() 转成标准的 *http.Response。如果问题是“响应状态到底是多少”，优先断言 rec.Result().StatusCode；响应头读 Result().Header，响应体则从 Result().Body 读取。rec.Code 和 rec.Body.String() 适合做局部、快速检查，但不是完整响应的替代品。

为什么读取状态要优先经过 Result

ResponseRecorder 实现了 http.ResponseWriter，handler 对它调用 WriteHeader、Write 或设置 Header 的变化都会被记录。直接看 rec.Code 能知道 recorder 记录到的状态，但它更接近“写入过程中的字段”。Result() 会把这些记录整理成标准响应，提供 StatusCode、Header 和 Body。

因此，接口测试通常把 recorder 当作收集器，把 result 当作断言对象。尤其是 handler 没有显式写状态时，不要自行用字段值推断隐式响应；让 Result() 负责给出 HTTP 语义上的状态。Result() 必须等 handler 完成后再调用。

package handler_test

import (
    "net/http"
    "net/http/httptest"
    "testing"
)

func TestCreateStatus(t *testing.T) {
    handler := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        // 先写明确状态，调用方才能按创建结果断言。
        w.WriteHeader(http.StatusCreated)
    })

    req := httptest.NewRequest(http.MethodPost, "/items", nil)
    rec := httptest.NewRecorder()
    handler.ServeHTTP(rec, req)

    // Result 只能在 handler 完成后读取，StatusCode 是标准响应字段。
    resp := rec.Result()
    if resp.StatusCode != http.StatusCreated {
        t.Fatalf("status = %d, want %d", resp.StatusCode, http.StatusCreated)
    }
}

这时也可以打印 rec.Code 做现场排查，但正式断言建议围绕 resp.StatusCode。这样后续要同时检查 Header 或 Body 时，不需要再把 recorder 的内部字段拼成一份“假响应”。

Header 和 Body 应该从哪个对象读取

在 handler 内部，w.Header() 是写入响应头的入口；handler 返回后，读取结果应使用 resp.Header。官方文档把 HeaderMap 标为历史兼容细节，并建议通过 Result() 返回的 Header 访问已经写出的头部。

头部还有一个容易漏掉的时间点：Result().Header 是第一次写入时的快照；如果 handler 已经写过状态或正文，再追加 Header，追加值不应被当作客户端能看到的响应头。工程上把所有 Header 设置放在 WriteHeader 或第一次 Write 之前最稳妥。

正文有两条读取路径。只想快速看字符串时，rec.Body.String() 很方便；要模拟标准客户端读取，则用 resp.Body 配合 io.ReadAll。后者更贴近调用方拿到的 http.Response，也更适合复用 JSON、文本或二进制解析逻辑。

func TestResponseParts(t *testing.T) {
    handler := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        // Header 必须在第一次写入前设置，避免错过响应快照。
        w.Header().Set("Content-Type", "application/json")
        w.WriteHeader(http.StatusOK)
        // 这是示例响应体，实际项目可替换为 JSON 编码结果。
        _, _ = w.Write([]byte(`{"ok":true}`))
    })

    rec := httptest.NewRecorder()
    handler.ServeHTTP(rec, httptest.NewRequest(http.MethodGet, "/health", nil))

    resp := rec.Result()
    defer resp.Body.Close() // 读取结束后释放响应体资源。
    body, err := io.ReadAll(resp.Body)
    if err != nil {
        t.Fatal(err)
    }
    if got := resp.Header.Get("Content-Type"); got != "application/json" {
        t.Fatalf("content type = %q", got)
    }
    if string(body) != `{"ok":true}` {
        t.Fatalf("body = %s", body)
    }
}

上面的示例还需要在 import 中加入 io。示例特意把状态、头部和正文放在同一个 resp 视图里，断言失败时能清楚区分是状态错、头部错还是正文错。

四个边界能避免 recorder 断言失真

1. 先设置头部。把 w.Header().Set 放在首次 WriteHeader 或 Write 前面。
2. 只让第一个状态生效。handler 先写了一个状态后再写第二个状态，不能把第二次调用当成最终状态。
3. 等待 handler 完成。异步逻辑还没结束就调用 Result()，读到的只能是当时的快照。
4. 断言稳定字段。官方说明返回的 Response 未来可能增加字段，所以比较 StatusCode、指定 Header 和 Body，不要比较整个对象。

关于 Go recorder 的几个延伸问题

rec.Code 和 resp.StatusCode 有什么区别？

rec.Code 是 recorder 记录的状态字段；resp.StatusCode 是 Result() 生成的标准响应状态。需要和 Header、Body 一起断言时，使用后者更一致。

为什么 HeaderMap 不建议继续使用？

它保留是为了历史兼容，官方文档已说明它属于内部细节。测试 handler 的响应头应从 Result().Header 读取。

读取 ResponseRecorder 的 Body 后还要关闭吗？

如果从 resp.Body 读取，应像处理普通 HTTP 响应一样关闭；直接调用 rec.Body.String() 做字符串检查时没有这个调用点。

把 recorder 用作写入收集器，把 Result() 用作响应断言入口，状态、头部和正文就能沿着同一条路径读取。遇到状态不对时，先查首次写入位置，再查 Header 设置时机，通常比继续打印内部字段更快定位。