Wire 生成普通 Go 代码而非反射或代理，因此依赖替换必须在编译前完成；wire.Build 必须放在独立的 wire.go 文件中，因其依赖 //go:build wireinject 构建约束和 go generate 的文件级解析机制。
Wire 不能在运行时动态替换依赖，它生成的是普通 Go 代码，不是反射或代理机制——这点不理解，后面所有配置都会走偏。
为什么 wire.Build 必须放在单独的 wire.go 文件里
Go 的构建工具链（go build、go generate）依赖文件级的 //go:generate 注释和包内可导出符号可见性。如果把 wire.Build 和业务逻辑混在一个文件里，wire 命令可能无法正确解析依赖图，尤其当构造函数带泛型或嵌套结构体时。
- 新建
wire.go，包声明与主包一致（如package main），且必须含//go:build wireinject构建约束 - 该文件中只保留
wire.Build调用和必要的空导入（_ "github.com/google/wire"），不写任何业务逻辑 - 执行
wire generate后，会生成wire_gen.go，它会被常规构建包含——但你绝不能手动修改它
wire.NewSet 和 wire.Struct 的边界在哪
新手常误以为所有依赖都要用 wire.NewSet 显式包装，其实 Wire 优先靠类型推导：只要构造函数签名明确（返回值类型唯一），Wire 就能自动匹配。只有当存在多个同类型构造器、或需要复用一组依赖时，才需 wire.NewSet。
-
wire.Struct用于注入 struct 字段，比如wire.Struct(new(MyService), "*")表示把所有字段按类型注入；若字段名是DB *sql.DB，Wire 会去找*sql.DB类型的提供者 - 若字段名是
db *sql.DB（小写），Wire 默认忽略——除非显式用wire.FieldsOf或在 struct tag 加wire:"-"控制 - 避免对简单值类型（如
string、int）直接使用wire.Value注入，容易导致多处硬编码；改用wire.Bind+ 接口抽象更可控
遇到 no provider found for *http.Client 这类错误怎么办
这不是 Wire 配置漏了，而是 Go 类型系统在“卡脖子”：*http.Client 是具体类型，Wire 不会自动帮你 new 出来，必须显式提供构造函数或绑定到接口。
- 最简方案：加一个函数
func NewHTTPClient() *http.Client { return &http.Client{} }，并把它加入wire.Build - 更合理做法：定义接口
type HTTPDoer interface { Do(*http.Request) (*http.Response, error) }，再用wire.Bind(new(HTTPDoer), new(*http.Client))建立映射 - 注意
*http.Client本身已实现Do方法，但 Wire 不会自动识别这种实现关系——必须靠wire.Bind显式声明 - 如果用了
http.DefaultClient，别直接wire.Value(http.DefaultClient)，它不是指针类型，会导致类型不匹配
测试时如何绕过 wire.Gen 直接替换依赖
Wire 生成的初始化函数是普通 Go 函数，参数和返回值都可见。测试时不需要启动完整依赖图，只需调用底层构造函数，或用 wire.Build 的子集重新生成轻量版初始化器。
- 在测试文件中写一个最小
wire.Build，只包含你要测的 service 及其直接依赖（比如 mock DB），然后wire generate -generate_path=mock_wire_gen.go - 不要在测试里 import
wire_gen.go，而应 import 你刚生成的mock_wire_gen.go，避免污染主流程 - 如果某个依赖难 mock（如
*redis.Client），用wire.Value注入一个 fake 实例，但务必确认该 fake 实现了所有被调用的方法，否则 panic 在运行时才暴露
Wire 的“编译时”本质，是指它把依赖组装逻辑提前到 go generate 阶段，生成的是可读、可调试、无反射的 Go 代码。真正容易被忽略的是：一旦生成了 wire_gen.go，后续修改构造函数签名后必须重新 wire generate，否则编译失败信息会指向生成文件里的某一行，而不是你实际改错的地方。
