直接用 httptest.NewRequest 和 httptest.NewRecorder 测试单个 Gin handler 是最稳最快的方式：构造请求（含 JSON body 和 Content-Type）、调用 handler.ServeHTTP(rr, req)，配合 gin.SetMode(gin.TestMode) 和 gin.CreateTestContext，断言状态码与解析后的响应结构体，覆盖所有错误路径。
直接用 httptest.NewRequest 和 httptest.NewRecorder 就能测通 handler，根本不用起真实服务——这是 Go 接口测试最稳、最快、最干净的方式。
怎么测单个 handler 函数（比如 Gin 的 POST /login）
核心是绕过网络层，把 handler 当普通函数调：构造请求、传入 recorder、检查输出。不占端口、无并发干扰、能断言内部状态（比如是否调了 DB 方法）。
-
httptest.NewRequest("POST", "/login", strings.NewReader(`{"email":"a@b.c","pwd":"123"}`))，记得手动设req.Header.Set("Content-Type", "application/json") -
rr := httptest.NewRecorder()后，直接调handler.ServeHTTP(rr, req)（Gin 需先gin.SetMode(gin.TestMode)，再用ctx := gin.CreateTestContext(rr)） - 别用
rr.Body.String()硬比 JSON 字符串——容易因空格、字段顺序、新增字段失败；改用json.Unmarshal(rr.Body.Bytes(), &actual)解析到结构体再断言字段 - 状态码从
rr.Code读，不是rr.Result().StatusCode（后者在 handler panic 时可能 panic）
为什么用 httptest.NewServer 反而容易出问题
它真监听端口，只该用于测「你写的 HTTP 客户端代码」，比如调第三方天气 API 的封装函数。拿来测自己的 handler，纯属自找麻烦。
- 忘记
defer server.Close()→ 测试进程卡住、CI 超时 - 并发测试里多个
NewServer→ 端口冲突，报错listen tcp 127.0.0.1:xxxx: bind: address already in use - 误以为
server.URL是裸端口 → 实际是完整 URL（如http://127.0.0.1:42135），拼接路径时写成server.URL + "/api"才对，不是"http://" + server.URL + "/api"
JSON 请求/响应处理的三个易错点
80% 的测试失败不是逻辑错，是 JSON 序列化/反序列化漏了错误处理或头没设对。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 发请求前，
body, err := json.Marshal(reqStruct)必须检查err != nil；别用fmt.Sprintf拼 JSON —— 引号、null、中文全会乱 - handler 里用
json.NewDecoder(r.Body).Decode(&v)后，必须检查解码 error，否则 400 请求可能静默跳过业务逻辑 - 响应体校验时，定义最小结构体（如
type loginResp struct { Msg string }），避免因 API 响应加了trace_id字段导致测试批量失败
错误路径（400/401/500）必须显式覆盖
只测 200 成功路径，等于没测。真实流量里，参数缺失、token 过期、DB 连不上才是常态，而这些路径往往没打日志或 panic 被 recover 吞掉，测试里根本发现不了。
- 为每个错误分支写独立测试用例：空 JSON body、缺 email 字段、密码太短、邮箱格式错、DB 查询返回
sql.ErrNoRows - handler 中所有
ctx.JSON(4xx, ...)或w.WriteHeader(500)，测试里必须用assert.Equal(t, 400, rr.Code)显式断言 - 别依赖中间件自动加 status code —— 测试要验证 handler 自己写的逻辑，不是验证中间件是否生效
真正难的不是写测试，是让每个错误分支都走到、每个 JSON 边界都校验到、每个 defer 都没漏掉——这些细节不抠，自动化测试就只是个摆设。
