Mock数据结构随API变更失效的典型表现
改了后端字段名或嵌套层级，Go测试里 mock.Mock 返回的 struct 一跑就 panic： panic: reflect.Set: value of type xxx is not assignable to type yyy。这不是 mock 框架的问题，是 Go 的类型系统在严格校验——你 mock 的 struct 类型和实际调用时期望的类型不一致了。
常见诱因：
• 后端返回新增了 StatusV2 字段，但 mock 数据还用旧版 Status
• 接口从返回 map[string]interface{} 切到强类型 ResponseData，而 mock 仍按 map 构造
• 使用 gomock 自动生成 mock 时，没同步更新 interface 定义，导致生成的 mock 方法签名错位
gomock + interface 重构时的 Mock 同步要点
Go 里靠谱的 mock 依赖显式 interface。API 变更后，必须同步三处，缺一不可：
- 先改真实代码中的 interface 定义（比如加一个
GetUserV2(ctx context.Context, id string) (*UserV2, error)） - 用
mockgen重新生成 mock 文件：mockgen -source=api.go -destination=mock_api/mock_api.go - 在测试中替换旧 mock 调用，注意新方法返回的是
*UserV2，不是*User—— 类型不兼容，不能靠赋值或强制转换绕过
别图省事在测试里用 struct{} 手动构造 mock 返回值。一旦字段增减，编译器不会报错，但运行时 JSON 解析或字段访问直接崩。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
JSON mock 数据硬编码的兼容性陷阱
很多团队用 json.Unmarshal([]byte{...}, &target) 加载 mock 响应体。API 字段变更后，这类测试常静默失败：
- 新增字段没出现在 mock JSON 里 → 对应 struct 字段为零值，逻辑分支未覆盖
- 字段类型变（如
"count": 5改成"count": "5"）→json.Unmarshal报json: cannot unmarshal string into Go struct field X.Count of type int - 字段重命名但 JSON key 没同步（如后端返回
"user_id"，struct tag 还是json:"id"）→ 字段始终为空
建议把 mock JSON 和 struct 定义放在同一文件，用 json.Marshal 反向生成样本（确保字段名、类型、tag 一致），而不是手写 JSON 字符串。
使用 testify/mock 时的版本感知实践
testify/mock 不像 gomock 那样绑定 interface，它靠方法名和参数匹配。这带来灵活性，也埋下隐患：
- 如果 API 方法名从
FetchUser改成GetUser，旧 mock 依然“能跑”，但实际没调用新逻辑 —— 因为 mock 对象里还挂着FetchUser的预期 - 参数类型变更（比如
id int→id string），mock.Expect() 不会报错，但运行时传参不匹配，mock 返回默认值，测试通过却漏测
对策：每次 API 变更后，在测试里搜 .Expect() 调用，逐个核对方法名、参数数量、参数类型是否与新 interface 一致；配合 mock.AssertExpectations(t) 确保所有预期被触发，避免“假通过”。
最麻烦的其实是嵌套 struct 的零值传播——比如 mock 返回的 User.Profile 是 nil，但业务代码没判空就直接取 User.Profile.AvatarURL，panic 发生在深层，错误堆栈不指向 mock 本身。这种得靠单元测试覆盖边界路径，光靠 mock 正确性不够。
