Go recorder 出错时怎么查Code 默认值

用 Go 的 httptest.ResponseRecorder 测试 handler 时，Code 读到 0 或 200，通常不是 HTTP 状态随机变化，而是 recorder 的创建方式和写入时机不同。httptest.NewRecorder() 会初始化一个可用的 recorder；如果直接使用零值结构体，Code 可能仍是 0。需要判断最终响应时，应等 handler 返回后调用 rec.Result().StatusCode，它才是更接近客户端视角的状态字段。

Code 为什么会出现 0 或 200

ResponseRecorder 是对 http.ResponseWriter 的记录器，不是真正监听端口的 HTTP 服务。它把 handler 对状态、头部和正文的修改收集起来，供测试稍后检查。官方源码中，NewRecorder() 返回的对象会把 Code 初始化为 200；而零值 ResponseRecorder 的整数默认值是 0。

这就解释了两种常见现象：如果测试使用了推荐的构造函数，刚创建时看到 200 并不奇怪；如果测试手动声明零值对象，或在自定义封装中清空了字段，看到 0 也不能马上理解成 handler 返回了 HTTP 0。真正的状态要看 handler 是否写过响应，以及最后通过哪个对象读取。

package handler_test

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

func TestRecorderStatusSource(t *testing.T) {
    // NewRecorder 会准备好 Body、HeaderMap 和初始状态，适合常规 handler 测试。
    ready := httptest.NewRecorder()
    if ready.Code != 200 {
        t.Fatalf("new recorder code = %d", ready.Code)
    }

    // 零值对象不会自动补齐构造函数设置，直接读 Code 可能得到 0。
    zero := new(httptest.ResponseRecorder)
    resp := zero.Result()
    if resp.StatusCode != 200 {
        t.Fatalf("result status = %d", resp.StatusCode)
    }
}

这段示例只说明字段来源，不建议在业务测试里用零值对象。常规路径使用 httptest.NewRecorder()，并在 handler 执行完以后读取结果，可以少掉一层初始化猜测。

先让 handler 完成，再读取 Result

Result() 不是把某个字段原样暴露出来，而是将 recorder 收集到的内容整理成 *http.Response。官方文档说明它至少提供 StatusCode、Header 和 Body，并且必须在 handler 结束后调用。对于“为什么 Code 不对”的排查，第一步就是把读取点移动到 ServeHTTP 返回之后。

如果 handler 调用了 WriteHeader，第一次有效状态会成为记录的状态；如果先调用 Write，recorder 会按 HTTP 的隐式规则记录 200。若完全没有写入，Result() 仍会把 0 转成标准响应视图里的 200。这也是直接断言 Code 和断言 StatusCode 可能不同的根源。

func TestHandlerStatus(t *testing.T) {
    handler := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        // 先写明确的业务状态，后续断言才有清晰的预期。
        w.WriteHeader(http.StatusAccepted)
    })

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

    // handler 已经返回，Result 才能代表这次处理形成的标准响应。
    resp := rec.Result()
    if resp.StatusCode != http.StatusAccepted {
        t.Fatalf("status = %d, want %d", resp.StatusCode, http.StatusAccepted)
    }
}

示例中的 http 包需要和 httptest 一起导入。这里只关心状态，所以没有把正文和头部混进断言；实际接口测试可以继续从同一个 resp 读取它们。

把状态、Header 和 Body 放进同一份断言

状态正常并不代表响应完整。Header() 是 handler 内部用来修改响应头的入口；handler 完成后，应该从 rec.Result().Header 检查已经形成的响应快照。正文可以快速查看 rec.Body.String()，也可以像处理普通响应一样从 resp.Body 读取并关闭。

func TestResponseParts(t *testing.T) {
    handler := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        // 首次写入前设置 Header，确保它进入返回响应的快照。
        w.Header().Set("Content-Type", "text/plain; charset=utf-8")
        w.WriteHeader(http.StatusOK)
        // 返回短正文，便于同时验证状态、头部和内容。
        _, _ = w.Write([]byte("queued"))
    })

    rec := httptest.NewRecorder()
    handler.ServeHTTP(rec, httptest.NewRequest(http.MethodGet, "/jobs/1", nil))
    resp := rec.Result()
    defer resp.Body.Close() // 使用 resp.Body 后及时关闭读取资源。

    if resp.StatusCode != http.StatusOK {
        t.Fatalf("status = %d", resp.StatusCode)
    }
    if got := resp.Header.Get("Content-Type"); got != "text/plain; charset=utf-8" {
        t.Fatalf("content type = %q", got)
    }
    body, err := io.ReadAll(resp.Body)
    if err != nil {
        t.Fatal(err)
    }
    if string(body) != "queued" {
        t.Fatalf("body = %q", body)
    }
}

这段代码还需要导入 io、net/http 和 net/http/httptest。关键不在于一次写完所有断言，而在于所有读取都发生在 handler 返回之后，并且使用同一份 resp。

遇到 Code 异常时按四个边界排查

1. 确认构造方式：优先使用 httptest.NewRecorder()，不要把零值对象当作完整 recorder。
2. 确认第一次写入：WriteHeader 或 Write 会确定状态和头部快照的时机。
3. 确认生命周期：不要在 goroutine 仍可能写响应时调用 Result()。
4. 确认断言对象：状态、头部、正文一起检查时，以 Result() 返回的 response 为主。

关于 Go recorder Code 的几个延伸问题

为什么 handler 什么都没写，Result().StatusCode 还是 200？

HTTP 响应存在隐式成功状态。recorder 的字段记录可能保留 0，但 Result() 会把零状态整理成标准响应中的 200，便于按客户端视角断言。

直接断言 rec.Code 是不是错的？

不是绝对错误。它适合快速确认 handler 是否写入了某个状态；但当测试还要检查 Header、Body 或未写入分支时，使用 Result().StatusCode 更稳定、更容易解释。

为什么第二次 WriteHeader 没有效果？

HTTP handler 的第一个有效状态会锁定响应状态，后续再写状态不会覆盖它。排查时沿着第一次 WriteHeader 或 Write 回看，而不是只看最后一行调用。

遇到 Go recorder 的默认值问题，先分清“构造函数给了什么”“handler 实际写了什么”和“Result 如何呈现”这三层。把读取点放在 handler 返回之后，再从标准 http.Response 同时检查状态、头部和正文，通常就能定位这类测试错误。