wire 通过显式声明依赖、解耦构造和隔离初始化提升 go 代码可测试性：依赖以参数传入，支持接口绑定与 provider 替换，测试时无需 mock 框架即可注入内存实例或桩对象。
wire 能直接提升 go 代码的可测试性，关键不在于它“支持测试”，而在于它强制你把依赖显式声明、解耦构造、隔离初始化逻辑——测试时只需替换 provider，无需 mock 框架或改业务代码。
为什么 wire 能让单元测试更简单
手动 new 一个 NewUserService 时，如果它内部调用 sql.Open 或 redis.NewClient，你就得在测试里启动真实数据库；而用 Wire 后，NewUserService 只接收 *sql.DB 和 *redis.Client 作为参数——测试时传入内存 mock 实例（比如 sqlmock.New() 或 gomock 生成的桩）即可，完全绕过真实依赖。
- 所有依赖必须通过函数参数传入，杜绝隐式全局状态
- provider 函数可被单独测试，比如验证
NewDBPool(config)是否正确设置了SetMaxOpenConns - injector 生成的代码是纯 Go，没有反射，测试覆盖率统计不受干扰
测试中如何替换 provider
Wire 不提供运行时替换能力，但允许你在测试专用的 injector 中使用不同的 provider。常见做法是：为测试新建一个 wire_test.go 文件，复用主 injector 的大部分依赖，只替换关键组件。
- 主
wire.go用components.NewDBPool提供真实连接池 - 测试文件
wire_test.go定义fakeDBPool()返回*sqlmock.Sqlmock，并用wire.Build替换掉原 provider - 调用
wire.Build(components.NewApp, fakeDBPool, components.NewCache)生成测试专用 injector
注意：wire.Build 是编译期指令，不同文件中的 injector 互不影响，不会污染生产构建。
接口绑定是测试解耦的核心技巧
Wire 的 wire.Bind 让你可以依赖接口而非具体类型，这是测试友好性的底层支撑。例如：
wire.Bind(new(UserRepository), new(*SQLUserRepository))
只要 SQLUserRepository 实现了 UserRepository 接口，业务代码就只依赖 UserRepository。测试时你完全可以写一个 MockUserRepository 实现同一接口，然后在测试 injector 中用 wire.Bind(new(UserRepository), new(*MockUserRepository)) 替换。
- 避免在 provider 函数签名里暴露具体实现类型（如
*sql.DB），优先用接口（如driver.Conn或自定义DBExecutor） - 对 string、int 等基础类型包装成新类型（如
type MySQLDSN string），防止多个 provider 争抢同一个string参数
容易忽略的测试陷阱
Wire 本身不报错，但测试失效往往源于 provider 设计缺陷：
- provider 函数带
context.Context且未设默认 timeout —— 测试可能卡死，建议用context.Background()或传入testCtx, cancel := context.WithTimeout(...) - provider 返回指针但没处理 nil 情况 —— 测试传入 mock 后，若业务代码未判空，panic 会掩盖真实问题
- 在 injector 函数里写逻辑（比如条件判断或日志）—— 这些代码不会被生成到
wire_gen.go，测试时根本不会执行，造成行为不一致
最隐蔽的问题是：provider 集合（wire.NewSet）被多处复用，但某次测试修改了集合内容，却忘了更新其他 injector 的 wire.Build 调用，导致测试跑的是旧依赖链。
