Wire是编译时依赖注入工具，通过代码生成实现零运行时开销、类型安全和显式初始化，需提前划分边界、收敛依赖入口并约束命名，否则易导致wire_gen.go失控或编译失败。
Wire 不适合“直接套用”在未经组织的大型项目里——它需要你提前划分边界、收敛依赖入口、约束类型命名，否则生成的 wire_gen.go 会迅速失控，甚至编译失败。
为什么 wire.Build 会报 “no provider found for *sql.DB”
这是大型项目中最常卡住的第一步：Wire 找不到某个类型的提供者。根本原因不是函数没写，而是：
- 提供者函数没被
wire.Build显式引用，或被错误地放在了非//+build wireinject文件中 - 类型不匹配：比如你注入的是
*sql.DB，但提供者返回的是sqlx.DB（即使底层兼容，Wire 也严格按类型匹配） - 包路径不一致：
main包里引用了db.NewDBPool，但实际该函数定义在internal/db，而go mod没正确 resolve 或import路径写错 - 构建约束失效：忘记在
wire.go顶部加//+build wireinject，导致wire命令压根没扫描这个文件
如何组织多模块项目的 wire.Set
把所有 provider 堆进一个 wire.Build 调用是大型项目的典型反模式。你应该按能力域分组，用 wire.NewSet 封装：
- 每个子模块（如
auth、payment、cache）各自导出一个ProviderSet变量，例如auth.Set、cache.RedisSet - 顶层
wire.go只组合这些 set：wire.Build(auth.Set, cache.RedisSet, payment.StripeSet)，不直接列函数名 - 避免跨模块循环引用：如果
payment需要auth.UserRepo，不要让payment.Set直接依赖auth.Set，而是通过接口 +wire.Bind解耦 - 测试专用 set 单独建：比如
test.MockDBSet，只在测试注入器里替换，不影响主流程
string、int 等基础类型注入失败怎么办
Wire 默认拒绝注入裸 string、int、bool——因为它们极易冲突（比如两个模块都想要一个 string 作为配置）。解决方式很明确：
- 为每个语义化用途定义新类型：
type HTTPAddr string、type MySQLConnString string、type CacheTTL time.Duration - 提供者函数必须返回这个新类型，不能返回裸
string；注入器参数也必须声明为该类型 - 别试图用
wire.Value强塞原始值——它只适用于极少数常量场景（如wire.Value(math.Pi)），且无法参与依赖推导 - 配置结构体优先：比一堆零散基础类型更安全，例如用
type Config struct { HTTPAddr HTTPAddr; DBConn MySQLConnString }+wire.Struct(new(Config), "*")
wire_gen.go 编译慢、diff 大、难以 Code Review
这是 Wire 在大型项目中最隐蔽的痛点：每次运行 wire，生成的文件可能有数百行，且顺序不稳定，git diff 像天书。关键控制点在于：
- 禁止手动修改
wire_gen.go——它应被视为“编译产物”，和go.sum一样只提交，不编辑 - 把
wire.go拆成多个小文件，按功能命名（如wire_http.go、wire_db.go），每个只负责一个子系统的 injector 声明 - CI 中加入
wire -check：确保本地生成的wire_gen.go和 CI 生成的一致，防止“忘了运行 wire”导致编译失败 - 对生成代码做最小化 lint：比如禁用
golint对wire_gen.go的检查，但保留go vet，避免生成非法语法
Wire 的威力不在“能用”，而在“约束力”——它强制你把隐式依赖显式化、把随意命名收敛为类型契约、把初始化逻辑从散落各处收束到几个可追踪的 wire.go 文件里。一旦越界（比如在 provider 里做 I/O、在 injector 里写业务逻辑），整个链条就容易断裂，而且错误提示往往藏在最深的调用栈里。
