httptest.newserver 适合测 http 客户端而非服务端，它启动独立 tcp 服务并返回硬编码响应，绕过真实路由与中间件；测服务端 handler 应用 httptest.newrecorder，其纯内存模拟 responsewriter，可精确捕获状态码与响应体。
httptest.NewServer 适合测 HTTP 客户端，不是服务端
很多人一看到 httptest 就默认用来“Mock 自己的 Web 服务”，结果跑起来发现路由没生效、中间件不触发、甚至 http.ServeMux 根本没被调用——因为 httptest.NewServer 启的是一个**独立进程级 HTTP 服务**，它只接收请求并返回你硬编码的响应，完全绕过你的实际 handler 和路由逻辑。
真正该用它的场景是：你在写一个 HTTP 客户端（比如调第三方 API 的封装），需要一个可控的远端地址来验证请求构造、重试、超时等行为。
- 用
httptest.NewServer时，你得自己写http.HandlerFunc模拟响应，和你的业务代码零耦合 - 它启动的是真实 TCP 端口，会占用资源，测试完必须调
srv.Close()，否则可能端口冲突 - 不支持 HTTPS，默认走 HTTP；要测 TLS 行为得换
httptest.NewUnstartedServer+ 手动配置tls.Config
httptest.NewRecorder 是测服务端 handler 的正确起点
想验证自己的 http.HandlerFunc 或 Gin/echo 路由是否按预期处理请求、写入状态码和 body，httptest.NewRecorder 才是直连核心。它不启网络，纯内存模拟 ResponseWriter，能精确捕获你 handler 里调 w.WriteHeader()、w.Write() 的所有输出。
典型误用是拿它去“测整个 HTTP 服务启动流程”，比如在测试里跑 http.ListenAndServe ——这既慢又难控制端口，还掩盖了 handler 本身的问题。
立即学习“go语言免费学习笔记（深入）”；
- 传给 handler 的
*http.Request必须用http.NewRequest构造，注意 method、URL、body 都得显式设好 -
req.Header.Set("Content-Type", "application/json")这类头设置不能漏，尤其测 JSON 解析时 - 如果 handler 依赖 context（如超时、trace ID），记得用
req = req.WithContext(...)注入 - 别直接断言
rec.Body.String()，先检查rec.Code是否为 200，再看 body 内容
第三方库 httprouter / Gin / Echo 的 Mock 要绕开框架启动逻辑
框架自带的测试辅助（如 Gin 的 gin.CreateTestContext、Echo 的 echo.New().NewContext）本质还是包装了 httptest.NewRecorder，但它们对中间件、路由匹配、绑定解析的支持程度差异很大。直接用原生 http.ServeMux + NewRecorder 反而更可控、更轻量。
例如用 Gin 时，如果你只测某个 handler 函数，没必要启动整个 gin.Engine：把 handler 提成包级函数，传入 http.ResponseWriter 和 *http.Request 即可单元测；只有涉及路由参数解析、中间件链路时，才用框架的测试上下文。
- Gin 的
c.ShouldBindJSON(&v)在测试中可能 panic，因为默认Content-Type是空的，得手动设req.Header.Set("Content-Type", "application/json") - httprouter 不支持直接 mock 路由树，得用
router.ServeHTTP(rec, req)，且需确保注册路径和测试请求路径完全一致（包括末尾斜杠） - Echo 的
echo.New().Router().Add()可以预注册路由，但测试时仍要调router.ServeHTTP()，别忘了echo.New().NewContext(req, rec)创建上下文
Mock 外部依赖（DB、Redis、第三方 API）别塞进 HTTP 测试里
HTTP handler 测试里混着 db.QueryRow 或 redis.Client.Get，等于把单元测试写成了集成测试：速度慢、不稳定、失败原因难定位。真正的 Mock 应发生在 handler 依赖的 service 层，而不是 HTTP 层。
比如 handler 调用了 userSvc.GetUserByID(ctx, id)，那就 mock 这个 userSvc 接口，而不是在测试里起个 fake Redis 实例或往 test DB 插数据。
- 用 interface 定义 service（如
type UserService interface { GetUserByID(context.Context, int) (*User, error) }），handler 只依赖 interface - 测试时传入 struct 实现该 interface，方法体直接 return 预设值或 error
- 避免用
monkey.Patch等运行时打桩，它破坏类型安全，且在 go test -race 下可能出问题 - 如果非要用真实依赖（如测 OAuth callback endpoint），至少用
httptest.NewServer模拟那个第三方服务，别连真环境
最常被跳过的一步：handler 里用了 log.Printf 或 zap.L().Info，但测试没重定向日志输出，导致失败时看不到关键调试信息。用 log.SetOutput(ioutil.Discard) 或 zap 的 ztest.NewLogger(t) 控制它。
