wire 是静态代码生成工具，通过分析 wire.build() 中声明的 newxxx 函数签名构建依赖图，生成纯 go 的 wire_gen.go 初始化代码，不运行、不反射、不注册，仅做编译期类型匹配与依赖解析。
Wire 不是“注入”，而是把 NewXXX() 函数按依赖图硬编码拼成一个初始化函数——它不运行、不反射、不注册，只生成 wire_gen.go。
wire.Build() 到底在做什么？
它只是个标记函数，告诉 Wire：“从这里开始分析，这些 Provider（NewDB、NewCache 等）是我声明的依赖构造入口”。Wire 不执行它们，也不调用它们，只静态扫描函数签名和返回类型，构建依赖关系图。
-
wire.Build()里列的每个函数必须是可导出的、有明确返回类型的普通 Go 函数（不能是方法、不能带未命名返回值） - 如果某个
NewX返回*sql.DB，而另一个NewY参数需要*sql.DB，Wire 就认为存在一条依赖边 - 它不理解业务逻辑，只做类型匹配：两个类型完全一致才连边；
interface{}或空接口无法被自动满足 - 一旦发现循环依赖（A→B→A），报错直接指向
wire.go行号，不是运行时 panic
为什么 wire_gen.go 看起来像手写代码？
因为就是手写风格。Wire 生成的 wire_gen.go 是纯 Go，没有任何 import 第三方 DI 库，所有对象创建顺序、参数传递、错误处理都展开为直白语句。
- 例如：
db := NewDB(...)→cache := NewCache(db)→svc := NewService(cache) - 如果某个 Provider 返回
(T, error)，生成代码会显式检查if err != nil并 return - 没有中间容器、没有 map 存储实例、没有 interface{} 类型擦除——所以 IDE 能直接跳转到
NewDB定义，调试时也能逐行跟进去 - 这也意味着：你不能在运行时换掉
cache实例，也不能基于环境变量决定用NewRedisCache还是NewMemCache——那些得靠 build tag 或多写几个wire.Build()变体
wire.Build 报错常见原因和定位方式
Wire 错误全在编译期暴露，但提示位置容易误导。关键看错误信息里是否含 wire_gen.go 或 wire.go。
-
cannot find provider for *http.Client：说明没人提供*http.Client类型，且没人在wire.Build()中声明对应NewHTTPClient函数 -
no required function found that returns type ...：Provider 函数名可能未导出（首字母小写），或返回类型多了error但调用处没声明接收 - 错误指向
wire_gen.go:123：别去修这个文件！这是生成结果，要回查wire.go里对应的wire.Build()调用和 Provider 声明 - 修改
NewXXX签名后忘记重新运行wire：生成代码不会自动更新，wire_gen.go会残留旧逻辑，导致编译失败或运行时 panic
什么时候不该用 Wire？
当你的依赖链需要动态决策、运行时热替换、或跨模块隐式共享单例时，Wire 会成为阻碍而非助力。
- 测试中想用 mock 替换真实
DB？Wire 要求你在wire.Build()里显式换掉NewDB——不如直接在 test 文件里传 mock 实例 - 想根据配置加载不同存储后端（S3 / LocalFS）？Wire 不支持条件分支，得拆成两套
wire.Build()+ build tag - 项目只有 3–4 个组件，
main.go里手动 new 三行就搞定：Wire 增加了wire.go、wire_gen.go、go:generate注释三处维护点，收益远小于成本 - 团队不熟悉代码生成流程，CI 中漏掉
wire命令，会导致wire_gen.go过期——这种问题比运行时 DI 的 panic 更难排查
Wire 的价值不在“自动”，而在“可验证的显式”。它强制你把依赖关系写死在类型系统里，而不是藏在文档或心智模型中。但这也意味着：每改一个构造函数签名，就得同步更新 wire.go 和重新生成——这点容易被忽略，直到 CI 报错才意识到。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
