Wire 是编译期依赖注入工具，通过声明式定义生成无反射、零开销的初始化代码；它要求依赖封装为结构体字段而非函数闭包，且 provider 函数返回类型必须导出、参数名与绑定一致，文件组织需避免循环引用。
Wire 是什么，为什么不能直接 new 依赖
Wire 不是运行时反射容器，它在编译前就生成硬编码的初始化代码。你写 new(MyService) 看似简单，但一旦服务间有嵌套依赖（比如 Handler 依赖 Repository，而 Repository 又依赖 DB 和 Logger），手动拼接就会迅速失控——漏传、类型错、生命周期不一致，全靠人肉检查。
Wire 的作用就是把这种“构造逻辑”声明化，再由工具自动生成可读、无反射、零运行时开销的 Go 代码。
Echo 路由 handler 怎么接入 Wire 构造链
Echo 的 echo.HandlerFunc 是函数类型：func(echo.Context) error。它本身不持有依赖，所以不能直接让 Wire “注入” handler 实例；必须把 handler 封装成结构体，把依赖作为字段声明。
- 定义
type UserHandler struct { repo *UserRepository; logger *zap.Logger } - 实现方法
func (h *UserHandler) GetUsers(c echo.Context) error - 在 Wire provider 函数里返回
&UserHandler{repo: repo, logger: logger} - 注册路由时用
e.GET("/users", userHandler.GetUsers)，不是userHandler本身
别试图让 Wire 生成一个闭包或匿名函数——它不支持函数值注入，只处理结构体实例和普通函数返回值。
立即学习“go语言免费学习笔记（深入）”；
常见 Wire 编译失败：provider 返回类型不匹配或未导出
Wire 报错如 "no provider found for *db.DB" 或 "cannot use unexported field" 很典型。根本原因通常是：
- provider 函数返回了未导出类型（比如
func() db.db，小写db包名或小写类型名） - provider 参数名与已有绑定不一致（例如写了
func(l *zap.Logger)，但其他地方提供的是*zerolog.Logger） - 忘记在
inject.go的//go:build wireinject文件中 import 对应包，导致类型不可见 -
Build函数里漏掉某个中间依赖，比如提供了*UserHandler却没提供它需要的*UserRepository
执行 wire gen ./wire 后，立刻看生成的 wire_gen.go——如果里面没出现你期望的 new(UserHandler) 调用，说明 Wire 根本没连通那条路径。
如何组织 wire.go 和 inject.go 文件避免循环引用
推荐两个文件分离：
-
wire.go：放在根目录或cmd/下，只含InitializeApp() *App这类顶层入口函数，import _ "yourapp/wire" -
wire/inject.go：用//go:build wireinject标记，只放ProviderSet和InjectXXX函数，**不 import 主应用包里的 handler 或 service 实现**，只 import 接口和基础依赖（*sql.DB,*zap.Logger等）
否则容易出现 import cycle not allowed：比如 handler.go import wire/，而 wire/inject.go 又 import handler.go 中的具体结构体——这会让 Go 编译器拒绝构建。
真正难缠的不是语法，是 provider 链里某处用了未导出字段、或类型别名没对齐；Wire 不报错但生成空函数，得盯紧 wire_gen.go 输出内容。
