Go微服务中真正的依赖注入必须满足三个条件：参数是接口、构造函数校验nil、依赖由main显式传入；NewUserService(*sql.DB)不算，因其暴露实现细节、无法替换依赖、运行时才panic。
Go 微服务里没有“依赖注入框架”这回事，所谓实现方案，本质是选构造函数怎么写、依赖图在哪组装、出错时堆栈是否指向真实源头。
为什么 NewUserService(db *sql.DB) 不算依赖注入
它把实现细节暴露给上层，测试时没法替换，运行时才 panic。真正有效的注入必须满足三个条件：参数是接口、构造函数校验 nil、依赖由 main 显式传入。
-
NewUserService参数必须是UserRepo接口，而不是*sql.DB或*UserRepoImpl - 接口定义要窄：只包含
GetByID(ctx, id)，别塞ExecRawSQL(ctx, sql, args) - 构造函数里加
if repo == nil { panic("repo is required") }，把崩溃点拉到初始化处，不是第一次调用时
wire.Build 报 “could not find provider for *xxx.Service” 怎么查
这不是 provider 缺失，而是 wire 在解析链路上卡在中间类型。常见原因全是路径和签名问题，跟逻辑无关。
-
wire.go第一行必须是//+build wireinject，前面不能有空格，后面不能带注释或逗号 - 所有 provider 函数（如
ProvideDB）必须和wire.Build在同一包内 -
wire.Build(InitializeApp, NewService, NewRepository)漏了NewDB？错误提示永远指向NewService缺*Repository，但根因是NewRepository自己缺*sql.DB -
wire.go必须放在目标入口函数所在目录下：你要生成cmd/myapp/InitializeApp()，它就得在cmd/myapp/目录里
同类型多实例（如主从 DB）怎么避免 wire panic
wire 对类型严格匹配，两个函数都返回 *sql.DB 就会报 multiple providers found for *sql.DB。它不看函数名，只认签名。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
- 用
wire.Value(primaryDB)和wire.Value(replicaDB)注入已创建的实例（适合配置驱动流程） - 用
wire.Struct(new(App), "primaryDB", "replicaDB")，前提是App结构体字段名导出、类型一致、且字段名能明确区分 - 别试图靠改函数名绕过：把
NewPrimaryDB()和NewReplicaDB()当 provider 没用，wire 不解析函数名
main.go 就是依赖图的源代码，别藏进 generate 文件
微服务启动顺序敏感，DB 必须早于 Service 初始化，这个顺序必须肉眼可读、可单步调试、可 git blame。
- 先调
sql.Open()，再传给NewUserRepo()，再把 repo 和 logger 一起传给NewUserService() - 所有初始化失败（比如 redis 连不上）必须立刻返回 error 或 panic，不能静默吞掉——否则后续组件拿到 nil 实例，堆栈指向调用处而非构造处
- 别在包级 init 或全局变量里初始化依赖，那会让依赖关系不可见、无法替换、难以测试
最易被忽略的点：依赖生命周期管理不在注入阶段，而在 shutdown 阶段。数据库连接、gRPC client、kafka producer 都需要 Close()，而 Go 没有析构函数——这部分必须在 main 启动后显式注册关闭钩子，不能指望容器自动处理。
