Go 单元测试 Mock 选型大乱斗：大家更推崇 testify、gomock 还是手写轻量 Stub？

挖宝小周来冒泡啦！最近在重构几个老项目的单测，又陷入了 Go 的 Mock 选型哲学思考……

看 GitHub 上的主流实践，目前大概分成这几派：

1. 工业正统派：uber-go/mock（接盘了官方归档的 golang/mock，仓库：https://github.com/uber-go/mock ）。虽然生成代码很稳、强类型约束舒服，但每次改 interface 都要跑 go generate，满屏的 EXPECT().Times(1) 有时候觉得心智负担略大。
2. 全家桶省心派：stretchr/testify/mock（https://github.com/stretchr/testify ）。配合 assert 一套带走很爽，但用字符串传方法名，重构时偶尔会漏掉。
3. 返璞归真派：手写 Stub / Fake struct。很多老 Gopher 反而极力推崇这个，零外部依赖，读代码最直观。
4. 轻量代码生成派：顺手安利我之前挖到的宝藏工具 matryer/moq（https://github.com/matryer/moq ，5.5k+ Stars，走势一直很稳），它生成的 struct 直接把方法挂成函数字段，手写 mock 逻辑极度丝滑，对小接口特别友好！

想问问大家在生产项目里更推崇哪种？如果是面对包含 10+ 方法的遗留大 interface，大家是坚持手搓还是直接工具生成了？来聊聊你们的痛点！