Go 用 httptest 测 Handler，为什么响应体是空的：WriteHeader、Result 与断言顺序

线上跑通的订单查询接口返回JSON完全正常，写单测的时候却报响应体是空的，往下看还发现rr.Code返回0，手忙脚乱补上一句WriteHeader(200)之后，又发现预先设置的自定义响应头直接不见了。这类问题不是httptest本身出bug，大多是写测试的时候把记录器状态、响应提交时机、取结果做断言这几件事混到同一时刻操作了。

你碰到的httptest空响应、状态码返回0、自定义头不生效这些问题，都不是测试框架本身故障，核心是没理清Go标准库net/http里响应提交的边界，同时测试代码里调用WriteHeader、获取Result、写断言的先后顺序搞错了。

故障现场：接口在线正常，测试里的 Code 却是 0

之前有次把 GET /orders/42 接口改成返回统一JSON格式的提交，浏览器和curl调都完全正常，CI跑单测却一直失败，报错信息只有一句：want 200, got 0。第一反应很多人会直接给Handler补个200状态码，这里不用急着改业务代码，先排查测试侧有没有真的让Handler往记录器里写入过内容。

func TestGetOrder(t *testing.T) {
    req := httptest.NewRequest(http.MethodGet, "/orders/42", nil)
    rr := httptest.NewRecorder()

    // 漏掉这一句时，rr.Code 仍是记录器的初始值 0。
    // getOrder(rr, req)

    if rr.Code != http.StatusOK {
        t.Fatalf("want 200, got %d", rr.Code)
    }
}

httptest.NewRecorder() 刚创建的时候还没有任何响应产生。如果Handler根本没被调用、路由没匹配上，或者逻辑走到一半提前返回完全没做任何写入，直接读 rr.Code 就会拿到0。这个值不是HTTP协议里的默认状态码，反而是很实用的测试提示信号：这轮请求没有产出任何可被记录的响应内容。

按时间线复查：什么时候响应才算正式提交

把Handler的执行过程看成有明确提交边界的流程就好理解了。设置Header只是修改待发送的元数据，还没真正发出去；等到第一次调用 WriteHeader 或者直接往Body里写内容的时候，当前的状态码和已经设置好的Header才会被固定下来。这之后再补 Content-Type 这类头字段，最后拿到的响应里大概率不会更新这个值。

func getOrder(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "application/json; charset=utf-8")
    w.WriteHeader(http.StatusOK)
    _, _ = w.Write([]byte(`{"id":42,"status":"paid"}`))
}

不少Handler不会显式调用 WriteHeader(200)，而是直接往Body写内容，这种场景下标准库会自动补200状态码。真正容易踩坑的是先写Body，之后才去设置头字段，或者错误分支已经把状态码写成400，后续逻辑又想覆写成200。如果写测试的时候只盯着返回的文本内容，很容易把这类提交顺序的问题掩盖过去。

最小可用测试：让断言跟随完整响应走

下面的写法适配绝大多数不需要绑定真实端口的Handler单测场景。先调用Handler，等它完全执行返回之后，再拿 Result。把Body里的内容读出来之后，用JSON反序列化做业务断言，比直接比对整段字符串兼容性好很多，不会因为字段顺序、空格换行的差异误判失败。

func TestGetOrder(t *testing.T) {
    req := httptest.NewRequest(http.MethodGet, "/orders/42", nil)
    rr := httptest.NewRecorder()

    getOrder(rr, req)

    res := rr.Result()
    defer res.Body.Close()

    if res.StatusCode != http.StatusOK {
        t.Fatalf("status: want %d, got %d", http.StatusOK, res.StatusCode)
    }
    if got := res.Header.Get("Content-Type"); got != "application/json; charset=utf-8" {
        t.Fatalf("content type: %q", got)
    }

    var payload struct {
        ID     int    `json:"id"`
        Status string `json:"status"`
    }
    if err := json.NewDecoder(res.Body).Decode(&payload); err != nil {
        t.Fatalf("decode response: %v", err)
    }
    if payload.ID != 42 || payload.Status != "paid" {
        t.Fatalf("unexpected payload: %+v", payload)
    }
}

这里的操作顺序不能随便调换。Result 本身就是设计成Handler执行完之后用来生成完整可读取响应对象的，如果在写入操作还没结束的时候就提前拿它做断言，拿到的Header快照和状态码很容易和最终实际输出的内容不一致。如果你的逻辑是流式输出、后台goroutine继续往响应写内容这类设计，建议把写入生命周期收回到Handler内部，不然就改用端到端测试来验证真实连接的表现。

根因不在Recorder本身时，优先查路由和错误分支

如果上面的最小用例能正常跑通，但是接入完整路由之后还是拿到空响应，问题基本出在测试夹具上。常见的场景包括请求方法写成了不匹配的POST、路径少了预设前缀，或者鉴权中间件拒绝请求的时候没有统一输出符合规范的JSON。把路由注册逻辑、请求方法、路径参数和依赖替身的状态都加到失败提示里，定位速度会快很多。

• 路由测试首先确认 router.ServeHTTP(rr, req) 真的被执行到，不要只单独创建了Handler就直接读结果。
• 带路径参数的Web框架要走框架本身提供的路由入口，直接单独调用Handler的话，上下文里的参数大概率根本不存在。
• 错误分支也要显式写出对应状态和响应体，不能直接空着return。
• 响应Body读完一次之后指针就走到末尾了，如果需要二次校验就把读到的字节内容存下来，不要期望第二次直接读还能拿到完整内容。

上线前的防复发检查

这类单测逻辑可以封装成统一的辅助函数，但辅助函数不要把错误细节全部吞掉。保留状态码、Content-Type、JSON解析错误、核心业务字段四类校验信息，出问题的时候直接看报错信息就能离根因很近。对会返回业务错误的接口，额外补充一组4xx场景的用例，确认业务失败时也能返回稳定符合契约的JSON结构。

1. 每个Handler的测试都显式调用目标Handler或者路由的统一入口。
2. 先把所有要设置的Header都配置好，再写状态码或者往Body里写内容。
3. Handler执行返回之后再调用 Result 方法。
4. 优先用JSON反序列化之后断言核心字段，同时补充非2xx状态的场景用例。
5. 跑一遍 go test ./...，确认全局公共中间件不会意外修改正常响应的格式。

常见问题

为什么 rr.Code 是 0，但 Result 的状态码看起来是 200？

前者直接反映记录器有没有真的收到写入操作，后者会按照HTTP协议的默认成功语义自动补全结果。排查「Handler是不是完全没写响应」这类问题的时候，0这个值的提示作用更明显；要验证最终返回的HTTP响应是不是符合预期，优先取Handler返回之后的Result对象校验就好。

一定要手写 WriteHeader(200) 吗？

不需要。直接往Body写内容的话标准库会自动补上200状态码。显式写出200的好处主要是把响应提交的点标得更清晰；如果是要返回非200的错误状态，或者要设置特殊的响应头，更要注意设置顺序不要搞反。

能直接比较 rr.Body.String 吗？

内容很短的固定文本场景可以用，但JSON格式的响应更适合反序列化之后对比结构和核心字段，测试不会被无关的格式差异影响，稳定性会好很多。

什么时候该从 httptest 切到真实服务测试？

如果逻辑依赖TLS握手、浏览器重定向、真实网络超时、连接复用或者多个中间件串起来的完整链路，再启动一个测试服务跑会更合适；普通Handler的状态码、响应头和JSON契约校验，用httptest的记录器速度足够快，逻辑也足够清晰。

把httptest当成完整响应的观察节点，而不是只用来拿返回的字符串，大部分「空响应」的问题很快就能找到本质：要么Handler根本没被执行到，要么响应提交顺序写反了，要么测试夹具没把完整的路由链路搭对。先把执行时间线理对，再谈断言写得够不够简洁优雅。