gock是测试时启用的请求拦截器，仅用于go test，必须在测试生命周期内严格启停；未调用gock.off()会导致残留规则污染后续测试，尤其并发时易引发匹配失败或panic。
gock不是部署工具，是测试时启用的请求拦截器
gock 不需要“部署”到微服务运行环境中，它只应在 go test 过程中启用，且必须在测试生命周期内严格启停。一旦测试结束未调用 gock.Off()，残留规则会污染后续测试（尤其是并发执行时），导致匹配失败或 panic。
-
gock.Off()必须放在defer中，且位置要早于任何实际 HTTP 调用 - 若使用
TestMain(m *testing.M)统一管理，需确保gock.Off()在os.Exit(m.Run())之前执行 - 禁止在
init()或包级变量中调用gock.New()—— 这会导致测试间状态泄漏 - 多测试文件共用同一域名模拟时，建议用
gock.Flush()替代gock.Off()，避免全局关闭影响其他测试
匹配规则写错会导致请求漏过或 panic
gock 匹配失败时默认静默放行真实请求，但若你期望拦截却没生效，往往是因为协议、host、path 或 header 的细节不一致。比如：
- 注册的是
gock.New("https://api.example.com")，但代码发的是http.Get("https://api.example.com/v1/users")→ 匹配成功 - 注册的是
gock.New("https://api.example.com")，但代码发的是http.Get("https://api.example.com:443/v1/users")→ host 不等（api.example.com:443≠api.example.com），匹配失败 - 用
.MatchType("json")但请求体是 raw string → 解析失败，匹配跳过 - 调用
.Post("/login").BodyString("user=alice")，但实际请求用了application/jsonheader → 默认 body 匹配不触发，需显式加.MatchHeader("Content-Type", "application/x-www-form-urlencoded")
别把 gock 当契约校验工具用
gock 只验证「是否发出请求」和「是否返回预设响应」，它完全不检查 JSON 字段是否存在、类型是否匹配、是否多字段或少字段。例如你 mock 返回 {"id": 1, "name": "Alice"}，但实际接口已改成 {"user_id": 1, "full_name": "Alice"}，gock 测试仍会通过。
- 真正需要契约保障的场景（如前后端联调、外包接口），应配合
go-swagger validate或spectral校验响应结构 - 若仅用于单元测试中隔离下游，gock 足够；但集成测试阶段发现字段漂移，说明测试策略缺位，不是 gock 的问题
- 想让 gock 报错字段缺失？得自己在测试里解析响应并断言，比如用
json.Unmarshal+testify/assert检查 key 和类型
HTTP 客户端未抽象时，gock 是唯一可行方案
如果你的业务代码直接调用 http.Get / http.DefaultClient.Do，又来不及重构接口抽象，gock 就是当前最轻量的补救手段 —— 它不需要改一行业务逻辑。
- 它通过替换
http.DefaultTransport实现拦截，对标准库客户端天然兼容 - 但要注意：自定义
http.Client且设置了非默认Transport时，gock 不会自动拦截，需手动调用gock.InterceptClient(client) - 第三方 HTTP 库（如
resty、req）若底层仍走http.DefaultClient，gock 有效；若自行封装 transport，则需确认是否被 gock 注入 - 长期来看，应尽快将外部调用封装为 interface，并用 gomock 或手写 fake 替代，否则所有 HTTP 行为都绑定在 gock 规则里，难以做行为驱动验证
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
