Wire要求显式声明所有依赖，包括间接依赖和基础类型，未导出类型、错误绑定顺序、跨包强耦合及缺失提供者均导致编译失败。
wire.Build() 里漏掉中间依赖，生成代码直接报 undefined
Wire 不会自动推导“间接依赖”，比如 Service 依赖 *DB，而 *DB 又依赖 Config，你只在 wire.Build() 里写了 NewService 和 NewDB，但没显式提供 Config 类型的构造函数（如 NewConfig()），生成的 wire_gen.go 就会报 undefined: Config。
常见错误现象：运行 wire generate 成功，但紧接着 go build 失败，提示大量未定义标识符。
- 所有参与构建的类型（结构体、接口、构造函数）必须首字母大写导出，且位于当前包或其子包中
-
wire.Build()参数列表必须包含整个依赖链上每个环节的提供者——哪怕只是Config这种基础值类型，也要有对应提供者（wire.Value或NewConfig()） - 外部模块依赖（如
github.com/sirupsen/logrus）需确保已go mod tidy，且其导出的构造函数能被 Wire 扫描到 - 生成后务必立即
go build验证，Wire 自身不报错 ≠ 生成代码可编译
用 wire.Struct() 填充字段，结果注入了 nil 指针
wire.Struct() 是按字段名 + 类型双重匹配的“自动填充”机制，它不关心字段是否必需，也不校验是否已有绑定。如果结构体有个字段叫 Logger，类型是 log.Logger，但你没注册任何 log.Logger 提供者，Wire 就会默默填 nil，运行时 panic。
使用场景：仅适合字段名与类型完全明确、且所有字段都有稳定绑定的简单结构体（如配置容器）。不适合业务逻辑层的 Service 或 Handler。
立即学习“go语言免费学习笔记（深入）”；
- 优先写显式构造函数（如
NewHandler(logger log.Logger, db *sql.DB)），再把它加入wire.Build()—— 控制力强，意图清晰 -
wire.Struct(MyStruct{}, wire.FieldsOf{})容易因字段重命名、类型微调而失效，调试困难 - 若某字段需条件初始化（如根据环境变量开关 debug 日志），必须走构造函数逻辑，
wire.Struct()无法表达分支
接口绑定写错顺序，wire.Bind() 不生效
wire.Bind() 的两个参数顺序不能颠倒：wire.Bind(new(Interface), new(*ConcreteImpl))。第一个参数是接口零值（用于类型占位），第二个是具体实现类型。写反了或传了非指针，Wire 会静默忽略该绑定，后续注入时仍找不到实现。
典型错误：把 wire.Bind(new(Repository), &UserRepo{}) 写成 wire.Bind(&UserRepo{}, new(Repository))，或漏掉 new() 直接传类型字面量。
- 接口绑定必须配对出现在同一
wire.Build()调用中，不能分散在不同文件里 - 绑定目标（第二个参数）必须是 *T 形式，且
T实现了第一个参数声明的接口 - 测试时替换实现，靠的是在测试专用的
wire.Build()中用wire.Value或 mock 构造函数覆盖原绑定，不是改wire.Bind()
多层级模块拆分后，wire_gen.go 编译失败
按功能拆分 wire.go（如 dal/wire.go、service/wire.go）很合理，但每个子模块的 wire_gen.go 必须能独立编译——这意味着它不能引用其他模块未导出的类型，也不能依赖尚未生成的其他 wire_gen.go。
容易踩的坑：一个子模块的提供者返回了另一个子模块的未导出类型，或跨包调用时路径写错（如 dal.NewDB 写成 dal.NewDb）。
- 每个
wire.go文件应只管理本包及子包内可访问的依赖，避免跨包强耦合 - 模块间依赖通过接口传递，而非具体结构体；接口定义建议放在公共包（如
pkg/interface） -
wire_gen.go必须提交进 Git，CI 流程里不能靠go generate动态生成——否则本地能跑，CI 可能因缺失文件失败 - 大型项目建议用
wire.NewSet()组织提供者集合，再在顶层wire.Build()中组合多个 set，比堆砌函数更易维护
wire.Build() 拉进来，或者被误当成可选字段跳过了。Wire 的编译时检查很严，但报错位置往往离问题根源隔了两层，得顺着生成代码往回追。 
