应优先使用构造函数注入mock——因其保障测试可预测性、依赖显式化和避免状态污染；setter注入仅适用于灰度开关等运行时切换场景，且需谨慎清理以防污染。
Mock应该塞进构造函数还是用Setter覆盖
构造函数注入更安全，Setter注入更灵活，但多数情况下你应该选构造函数——不是因为“原则”，而是因为测试可预测性、依赖显式化和避免状态污染。
常见错误现象：TestXxx 里调用 SetClient 后，其他测试用例意外复用该 mock，导致偶发失败；或者忘记调用 SetClient，测试跑在真实 HTTP 客户端上，CI 偶然超时或失败。
- 构造函数注入：依赖在创建时就确定，实例生命周期内不可变，
NewService的参数直接暴露依赖契约 - Setter 注入：适合需要运行时切换行为的场景（比如灰度开关），但测试中容易漏设、误设、重复设
- 如果结构体字段是
exported（首字母大写），有人会直接s.Client = mockClient—— 这比 Setter 更危险，绕过任何封装逻辑，且 IDE 不提示
哪些情况必须用Setter或字段赋值
只有两类真实需求值得破例：需要复用同一实例做多组不同 mock 的对比测试；或被测类型本身不归你控制（比如第三方 SDK 的 struct），无法改构造函数。
使用场景举例：测试一个重试逻辑，需模拟第一次失败、第二次成功，这时用同一个 service 实例，通过 Setter 动态换掉内部 http.Client 对应的 mock。
立即学习“go语言免费学习笔记（深入）”；
- 务必在每个测试用例末尾恢复原始依赖（或用
defer清理），否则污染后续测试 - 避免在
init()或包级变量里做 Setter 赋值，那会让整个包的测试失去隔离性 - 如果用了 Setter，建议在结构体文档里明确写：“仅用于测试，非并发安全”
构造函数参数太多怎么办
不是“参数多”本身有问题，而是你可能把不该由调用方决定的东西塞进了构造函数——比如日志器、监控器、配置对象。这些应该抽成独立选项（Option）或用配置结构体传入。
性能影响几乎为零，但可读性差的构造函数会让测试代码冗长，也掩盖真正关键的依赖。
- 用函数式选项模式：
NewService(WithHTTPClient(mockClient), WithLogger(testLogger)) - 避免把
*testing.T或context.Context塞进构造函数——它们属于调用时上下文，不是组件依赖 - 如果发现构造函数里有 4 个以上参数且类型相似（比如全是
io.Reader），大概率职责过重，该拆了
Go 1.21+ 的泛型 Option 模式是否值得用
不推荐在 Mock 场景下引入泛型 Option。它解决的是类型安全的配置组合问题，而 Mock 关注的是依赖替换的清晰性和可控性。加一层泛型只会让测试代码更难一眼看懂哪块被替换了。
兼容性没问题，但调试时你会多一层跳转：从 WithHTTPClient 进到泛型方法，再进到具体字段赋值——而构造函数参数或普通 Setter 是直来直去的。
- 泛型 Option 适合构建复杂客户端（如数据库驱动、gRPC 连接池），不适合 service 层单元测试
- 如果团队已统一用泛型 Option，mock 相关的 option 应该命名明确，例如
WithMockHTTPClient，而非复用通用WithClient - 别为了“时髦”在测试 setup 里写
func() ClientOption闭包——它让 mock 行为变得隐式且难以追踪
最常被忽略的一点：很多人只 mock 接口，却忘了检查接口实现是否真的覆盖了所有被测路径。比如 Do() 方法被调用，但 mock 没实现 Close()，而被测代码恰好在 defer 里调了它——panic 就发生在测试之外。
