Go中工厂模式用函数、结构体和接口组合实现解耦，核心是统一入口与可扩展策略，而非模拟OOP；推荐map[string]func() Interface注册构造函数，辅以选项模式处理复杂参数。
Go 语言没有类和继承，所谓“工厂模式”不是照搬 Java 那套接口+抽象类+子类实现，而是用函数、结构体和接口组合出等效行为——关键在于解耦创建逻辑，而不是模拟 OOP 范式。
为什么 Go 里不用 newXXX() 函数当工厂
直接写 newUser()、newOrder() 看似简单，但一旦类型增多、创建逻辑变复杂（比如要读配置、校验参数、初始化依赖），就会出现重复代码或条件分支爆炸。真正的工厂价值在「统一入口 + 可扩展创建策略」。
- 常见错误：把工厂写成一堆 if/else 判断字符串返回不同结构体指针，没封装行为，也没利用 Go 接口的隐式实现特性
- 正确思路：定义一个创建函数类型（如
func() Service），让不同实现注册进来，调用方只认接口，不关心具体构造过程 - 性能影响几乎为零——函数值本质是闭包指针，调用开销可忽略；比反射安全且快得多
用 map[string]func() 接口 实现简单工厂
这是最常用、也最符合 Go 习惯的轻量级工厂：用字符串标识类型，用函数字面量封装构造逻辑，注册到全局 map 中。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
// 定义接口
type Processor interface {
Process(data string) error
}
<p>// 具体实现
type JSONProcessor struct{}
func (j JSONProcessor) Process(data string) error { /<em> ... </em>/ }</p><p>type XMLProcessor struct{}
func (x XMLProcessor) Process(data string) error { /<em> ... </em>/ }</p><p>// 工厂注册表（建议放 init 或显式初始化）
var processors = make(map[string]func() Processor)</p><p>func init() {
processors["json"] = func() Processor { return &JSONProcessor{} }
processors["xml"] = func() Processor { return &XMLProcessor{} }
}</p><p>// 工厂函数
func NewProcessor(typ string) (Processor, error) {
ctor, ok := processors[typ]
if !ok {
return nil, fmt.Errorf("unknown processor type: %s", typ)
}
return ctor(), nil
}- 注意
processors是map[string]func() Processor，不是map[string]Processor——后者会立即实例化，无法支持带参数或需延迟初始化的场景 - 注册时机很重要：
init()最简，但若构造函数依赖外部配置（如 DB 连接），应改用显式RegisterProcessor(name, ctor)函数 - 别在工厂里做 heavy 初始化（如打开文件、连数据库），那是具体类型的
NewXXX()该干的事
用选项模式（Option Pattern）替代复杂参数工厂
当构造函数需要多个可选参数（比如超时、重试次数、日志器），硬塞进工厂函数签名会很快失控。Go 社区通用解法是选项模式，它比传统工厂更灵活、更易测试。
立即学习“go语言免费学习笔记（深入）”；
type ClientOption func(*Client)
<p>func WithTimeout(d time.Duration) ClientOption {
return func(c *Client) { c.timeout = d }
}</p><p>func WithLogger(l <em>log.Logger) ClientOption {
return func(c </em>Client) { c.logger = l }
}</p><p>func NewClient(opts ...ClientOption) <em>Client {
c := &Client{timeout: 5 </em> time.Second}
for _, opt := range opts {
opt(c)
}
return c
}- 这本质上是“构造函数的 DSL”，不是传统意义上的工厂，但解决了工厂最难的部分：参数爆炸和可读性差
- 所有选项函数必须是无副作用的纯配置操作；如果某个选项需要执行 IO 或 panic，说明职责越界了
- 与上一种 map 工厂不冲突——你可以用选项模式构造具体类型，再把构造函数注册进 map
真正难的不是写一个能返回不同对象的函数，而是决定哪些逻辑该放进工厂、哪些该交给调用方。比如连接池、缓存实例、上下文绑定——这些往往该由上层组件（如 HTTP handler）传入，而不是让工厂自己 new 出来。Go 的工厂，八成功夫花在“不做什么”上。
