应使用 httptest 启动假服务器而非真实 http 服务，结合 testify/assert 进行状态码与 json 响应断言，并通过 interface 抽象外部依赖实现 mock，确保测试聚焦 handler 逻辑与协议行为。
用 net/http/httptest 启动假服务器，别真起服务
真实启动 HTTP 服务再测，会引入端口冲突、并发干扰、清理麻烦等问题。Go 标准库的 httptest 提供内存级请求响应闭环，无需网络栈参与。
实操建议：
- 用
httptest.NewServer或httptest.NewRecorder，前者适合集成测试（含路由中间件），后者适合单元测试（直调 handler 函数） - 若 handler 依赖
*http.Request和http.ResponseWriter，直接传httptest.NewRequest和httptest.NewRecorder即可，不走 net.Listen - 注意：用
NewServer时记得在defer server.Close()，否则测试进程可能卡住
用 testify/assert 检查响应状态和 JSON 字段，别手写 if !ok
手动解析 resp.Body、逐字段比对、检查错误码，容易漏掉空指针或类型断言 panic。第三方断言库能统一错误提示、支持深度比较、跳过无关字段。
实操建议：
- 状态码检查用
assert.Equal(t, http.StatusOK, resp.StatusCode)，比if resp.StatusCode != 200更易定位失败位置 - JSON 响应体推荐先解码到结构体（带
json:tag），再用assert.Equal整体比对；避免字符串正则匹配或部分字段 assert，否则字段顺序/空格/换行都可能误报 - 若只关心几个字段，可用
assert.JSONEq（来自testify/assert），它忽略键序和空白，但要求输入是合法 JSON 字符串
测试中 mock 外部依赖，比如数据库或 Redis，别连真实实例
API 测试不是集成测试——它的目标是验证 handler 逻辑与协议行为，而非后端服务稳定性。连真实 DB/Redis 会导致测试慢、不可靠、需预置数据。
实操建议：
- 把数据访问层抽象为 interface（如
type UserRepository interface { GetByID(id int) (*User, error) }），测试时注入 mock 实现 - 用
gomock或手写匿名 struct 实现 mock，重点覆盖 error 分支（如return nil, errors.New("timeout")），验证 handler 是否正确返回 500 或降级响应 - 不要在测试里调
sqlmock或miniredis——它们模拟的是驱动行为，而 handler 层不该感知 SQL 或 Redis 命令细节
用 go test -run=TestAPI.* -v 过滤并查看详细输出，别让失败淹没在日志里
API 测试常批量运行多个 endpoint，一个失败时默认输出只显示 panic 或第一行错误，看不出是哪个 case、什么请求参数、响应体长什么样。
实操建议：
- 每个测试函数名带上路径和方法，如
TestAPI_GetUserByID_200、TestAPI_PostOrder_400_MissingField，方便-run精准触发 - 在断言前加
t.Logf("request: %+v, response body: %s", req, body)，失败时自动打印上下文 - 避免在测试中用
log.Printf——它不随-v输出，也不绑定测试生命周期；一律用t.Log或t.Logf
真正难的不是写断言，而是让每个测试只验证一件事，并且失败时一眼看懂哪条契约被打破了。handler 逻辑、HTTP 协议、外部依赖这三层必须切开，否则改个 status code 都得重跑整个数据库链路。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
