Go 中的依赖注入：Web API 需要多少才算足够？

I’m happy to help translate the article, but I need the full text you’d like translated. Could you please paste the content here (excluding the source line you’ve already provided)? Once I have the text, I’ll translate it into Simplified Chinese while preserving the formatting, markdown, and any code blocks.

介绍

在 Go 语言中，依赖注入（DI）常常引发的争论，往往与大多数 Web API 的实际需求不成比例。讨论很快就会升级到容器、生命周期、作用域以及动态解析——尽管事实上许多服务只拥有一个简单、静态的依赖图，并且只在启动时解析一次。

关键点：
对于典型的 Web API，编译时依赖解析已经足够。

典型 Go Web API 的特征

• 无状态请求处理
• 依赖在启动时一次性解析
• 大多数为树形依赖图

config → database → repository → service → handler

• 运行时不重新绑定实现

在这种环境下，DI 并不是为了运行时的灵活性；它关注的是 wiring 的正确性和可维护性。

当运行时 DI 框架显得大材小用

Frameworks such as fx, dig, or generics‑based containers like do shine when an application behaves like a framework itself:

• Modules register themselves dynamically
• Lifecycle hooks (start/stop) matter
• Plugins or optional components are loaded at runtime

For typical web APIs, these features often bring downsides:

• Additional APIs to learn and remember
• Runtime error surfaces for what is fundamentally static wiring
• Harder‑to‑follow control flow during startup

When dependencies are fixed and known ahead of time, runtime DI solves a problem you don’t really

（译文）

当运行时 DI 框架显得大材小用

像 fx、dig 或基于泛型的容器 do 在应用本身表现得像框架时表现出色：

• 模块动态注册
• 生命周期钩子（启动/停止）很重要
• 插件或可选组件在运行时加载

对于典型的 Web API，这些特性往往带来负面影响：

• 需要学习和记住的额外 API
• 对本质上是静态 wiring 的运行时错误暴露
• 启动期间的控制流更难跟踪

当依赖在编译时已固定且已知时，运行时 DI 解决的是你其实并不需要的问题。

使用 wire 的静态依赖注入

wire 提供编译时依赖解析，无需运行时容器，生成纯 Go 代码。该模型具备：

• 安全且可预测
• 零运行时 DI 开销

Wire 的设计

• 提供者函数
• 提供者集合
• 每个根的注入函数

虽然显式性很有价值，但它也可能成为维护负担：

• 随着依赖图演变，提供者集合需要不断更新
• DI 专用文件会与业务代码一起增长
• 连线本身也成为开发者需要思考的内容

最小化静态 DI 与字段标签生成器

如果你想要静态装配和生成构造函数，但又希望减少 DI 相关的代码，可以使用更简洁的模型：

type Container struct {
    Handler *UserHandler `inject:""`
}

生成的代码就是普通的 Go：

func NewContainer() (*Container, error) {
    cfg := NewConfig()
    db, err := NewDatabase(cfg)
    if err != nil {
        return nil, err
    }
    svc := NewUserService(db)
    h := NewUserHandler(svc)
    return &Container{Handler: h}, nil
}

• 无运行时容器
• 无提供者集合
• 无反射

这就是 injector 背后的思路——仅使用字段标签的 DI 代码生成器。

当 Wire 仍然有意义时

• Provider sets 被视为公共组合 API
• 显式的 wiring 边界是有意的设计目标
• DI 图被审查并作为一等工件进行策划

换句话说，wire 的优势在于组织性和流程驱动。如果你的项目不需要如此程度的显式性，wire 就更难以证明其合理性。

Comparison

结论

对于常见的情况——无状态的 Web API 并且依赖图稳定——静态接线已经足够。减少需要维护的 DI 相关代码量会带来更好的结果。

对于大多数 Go Web API 来说，依赖注入并不需要成为框架层面的决策。它只是一个启动细节：

1. 只解析一次依赖。
2. 生成普通的 Go 代码。
3. 让接线保持单调。

如果 wire 感觉足够但有点笨重，基于字段标签的方式（injector）是一个自然的下一步。从这个意义上说，它并不是一种激进的替代方案；它只是提出了一个问题：

如果静态 DI 已经足够… 为什么不让它更简单？