Go不推荐硬套经典工厂模式，因其无类继承和构造函数重载，接口隐式实现，照搬Java/C#三层结构反而加重代码、降低可测性与可维护性；更倾向用函数类型、组合和接口实现解耦。
为什么 Go 里不推荐硬套经典工厂模式
Go 没有类继承、没有构造函数重载、接口是隐式实现的——这意味着你照搬 Java/C# 里的 FactoryInterface + ConcreteFactory + Product 三层结构，反而会让代码变重、难测试、不易维护。Go 更倾向用组合、函数值和接口来达成“解耦创建逻辑”的本质目标，而不是模式名称本身。
用函数类型替代工厂接口更符合 Go 习惯
把创建逻辑封装成函数，类型清晰、可传参、可闭包捕获依赖，比定义一堆空接口和实现结构体自然得多。比如要创建不同类型的数据库客户端：
type DBClient interface {
Query(string) error
}
type MySQLClient struct{}
func (m MySQLClient) Query(q string) error { / ... / }
type PostgreSQLClient struct{}
func (p PostgreSQLClient) Query(q string) error { / ... / }
// 工厂函数类型
type ClientFactory func(host, port string) DBClient
var MySQLFactory ClientFactory = func(host, port string) DBClient {
return MySQLClient{} // 可实际初始化连接池等
}
var PGFactory ClientFactory = func(host, port string) DBClient {
return PostgreSQLClient{}
}
// 使用时直接调用
db := MySQLFactory("127.0.0.1", "3306")
- 不需要定义
Factory结构体或方法，避免无意义的包装 - 工厂函数可带参数，也可通过闭包预置配置（如
func() DBClient { return MySQLClient{timeout: 5} }） - 测试时可直接替换为 mock 工厂函数，无需 mock 接口实现
结合依赖注入容器时，工厂常藏在 Builder 或 Provider 里
在使用 fx、wire 等 DI 工具时，“工厂”通常表现为一个返回具体实例的函数，并由工具自动管理生命周期。例如 wire 中：
func NewMySQLClient(cfg Config) (*sql.DB, error) {
return sql.Open("mysql", cfg.DSN)
}
func NewApp(mysqlDB sql.DB) App {
return &App{db: mysqlDB}
}
// wire.Build 会自动识别 NewMySQLClient 是创建 *sql.DB 的“工厂”
-
NewMySQLClient就是工厂函数，但它不叫MySQLClientFactory，也不实现某个接口 - 它可能返回错误、接受配置、复用已有依赖（如
Config），这比静态工厂更贴近真实场景 - 硬加一层
type ClientFactory interface { Create() DB }反而切断了错误传播和参数传递路径
什么时候真需要结构化工厂？仅当创建逻辑需状态或策略切换
如果工厂本身需要维护状态（如连接数限制、负载均衡选择器），或者要根据运行时条件动态切换策略（如按 region 选不同云存储客户端），才值得封装成结构体：
立即学习“go语言免费学习笔记（深入）”；
type StorageFactory struct {
mu sync.RWMutex
counts map[string]int
}
func (f *StorageFactory) NewClient(region string) StorageClient {
f.mu.Lock()
f.counts[region]++
f.mu.Unlock()
switch region {
case "us-east-1":
return &S3Client{}
case "cn-north-1":
return &OSSClient{}
default:
return &DummyClient{}
}
}
- 这种结构体工厂不是为了“符合模式”，而是因为确实需要共享状态或复杂决策逻辑
- 仍应让方法返回接口（
StorageClient），而非具体类型 - 注意并发安全：字段访问必须加锁，或改用
sync.Map等线程安全类型
真正容易被忽略的是：Go 项目里大多数“对象创建”根本不需要工厂——直接调用构造函数（如 NewXXX()）+ 接口赋值就足够轻量。强行抽象，往往是因为过早担心“以后要换实现”，但 Go 的接口替换成本极低，等真要换时再抽也来得及。
