不用DI容器也能实现清晰可测可运维的依赖管理，关键在于构造函数注入+接口抽象+显式串联；避免dig/fx等运行时反射框架导致依赖图不可见、IDE跳转失效、循环依赖仅运行时报错、调试困难及配置热替换失控。
不用 DI 容器也能做到清晰、可测、可运维的依赖管理——关键在构造函数注入 + 接口抽象 + 显式串联。
为什么别用 dig/fx 做主干依赖注入
运行时反射型 DI 框架（如 dig、Fx）会让 main.go 失去依赖图的“源代码”地位。你无法一眼看出 *OrderService 是怎么拿到 *redis.Client 的，IDE 跳转失效，go vet 和静态分析也帮不上忙。更麻烦的是：循环依赖只有运行到 fx.New() 才报错，提示类似 "cycle detected"，但错误堆栈指向生成代码而非原始 provider 函数。
微服务启动本就该显式表达顺序和边界，强行藏进 tag 或匿名结构体里，反而增加理解成本。
- 调试时无法直接断点进构造逻辑，只能在 invoke 阶段抓 panic
- 无法对某个依赖做条件替换（比如测试时用 mock，生产用 real）
- 热重载配置或灰度切换实现时，DI 容器的模块机制比手写
if env == "test"更难控制
构造函数注入必须带校验逻辑
依赖不是传进去就完事，得确认它真能用。比如数据库连接不能只检查指针非空，还得 db.PingContext(ctx)；gRPC 客户端不能只 new 出来，得尝试 conn.Connect() 并等待 ready。
示例中常见错误是把校验丢到第一次业务调用时才做，导致服务已上线但首次请求失败：
func NewOrderService(db *sql.DB, userClient UserClient) (*OrderService, error) {
if db == nil {
return nil, errors.New("db is nil")
}
// ❌ 错误：没验证连通性
// ✅ 正确：加 Ping
if err := db.PingContext(context.Background()); err != nil {
return nil, fmt.Errorf("failed to ping db: %w", err)
}
return &OrderService{db: db, userClient: userClient}, nil
}
- 所有关键依赖（DB、Cache、下游 HTTP/gRPC Client）都应在
NewXXX里完成基础连通性校验 - 校验失败应返回
error，而不是panic—— 启动阶段失败要可捕获、可日志、可告警 - 避免在
Init()函数或包级变量中隐式初始化，那会让依赖不可见、不可替换
启动顺序必须按 DAG 显式编码
服务不是并行启动的。ConfigLoader → Logger → DB → Cache → HTTP Server 是典型拓扑，跳过或颠倒顺序会导致 panic 或静默失败（比如日志组件没起来，DB 连接失败日志就丢了）。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
推荐封装一个 App 结构体，把依赖实例和启动顺序一起管理：
type App struct {
db *sql.DB
cache *redis.Client
svc *OrderService
server *http.Server
}
<p>func (a *App) Run() error {
if err := a.initDB(); err != nil { return err }
if err := a.initCache(); err != nil { return err }
a.svc = NewOrderService(a.db, a.cache, a.logger)
a.server = &http.Server{Addr: ":8080", Handler: a.router()}
return a.server.ListenAndServe()
}</p>
- 不要依赖 init() 函数自动执行，顺序不可控且无法注入 context
- 每个
initXXX()方法应返回error，便于上层统一处理失败 - Stop() 必须逆序执行：先关 HTTP Server，再关 Cache，最后 Close DB —— 否则关掉 DB 后，Cache 里的 goroutine 还在往已关闭连接写数据
依赖地址和超时必须配置驱动
硬编码 "http://user-svc:8080" 或 5 * time.Second 是 DevOps 场景下的高危操作。环境迁移、灰度发布、压测隔离全会崩。
正确做法是把地址、超时、重试次数都从配置中心或环境变量加载：
type UserClient struct {
httpClient *http.Client
baseURL string
}
<p>func NewUserClient(cfg Config) *UserClient {
return &UserClient{
httpClient: &http.Client{
Timeout: cfg.Timeout,
},
baseURL: cfg.BaseURL,
}
}</p>
- Kubernetes 下优先用 DNS 名（如
user-svc.default.svc.cluster.local），由 kube-dns 解析，不引入额外注册中心 - HTTP/gRPC 调用必须用
context.WithTimeout，禁用http.Get()这类无上下文函数 - 重试必须区分错误类型：
503、连接拒绝值得重试；400、404重试毫无意义
最易被忽略的其实是依赖关闭顺序和健康检查聚合。很多服务只实现了 /healthz，却没把下游 DB、Redis、核心 gRPC 服务的连通性纳入 /readyz 判断——结果 Kubernetes 把流量切过去，而服务其实根本没法查缓存或写库。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
