go中无需factory类，因接口+构造函数（如newxxx）已自然实现解耦与替换；工厂即带错误处理的类型化构造函数，应避免冗余结构体和隐式初始化。
Go 语言没有类和继承，所谓“工厂模式”不是靠抽象基类+子类实现的，而是用接口 + 函数返回具体结构体来达成解耦。直接写一个 NewXXX 函数往往就足够了，过度模仿 Java/C# 的工厂类反而会让代码变重、难测、难维护。
为什么 Go 里不需要 Factory 类
工厂模式的核心诉求是：把对象创建逻辑集中、隔离变化、便于替换实现。Go 中靠以下机制自然满足：
-
interface{}定义契约，调用方只依赖接口，不关心具体类型 - 构造函数（如
NewReader,NewHTTPClient）本身就是“工厂函数”，返回接口或指针 - 结构体字面量初始化 + 方法集自动满足接口，无需显式声明“实现”
- 依赖注入通常通过参数传入接口，而非工厂实例去“生产”它
最简可行的工厂函数写法
比如要支持多种日志后端（控制台、文件、网络），先定义接口：
type Logger interface {
Info(msg string)
Error(msg string)
}然后为每种实现写独立的构造函数，不包在 struct 里：
立即学习“go语言免费学习笔记（深入）”；
type consoleLogger struct{}
<p>func (c <em>consoleLogger) Info(msg string) { fmt.Println("INFO:", msg) }
func (c </em>consoleLogger) Error(msg string) { fmt.Println("ERROR:", msg) }</p><p>func NewConsoleLogger() Logger {
return &consoleLogger{}
}</p><p>type fileLogger struct {
f *os.File
}</p><p>func (f <em>fileLogger) Info(msg string) { fmt.Fprintln(f.f, "INFO:", msg) }
func (f </em>fileLogger) Error(msg string) { fmt.Fprintln(f.f, "ERROR:", msg) }</p><p>func NewFileLogger(filename string) (Logger, error) {
f, err := os.OpenFile(filename, os.O_WRONLY|os.O_CREATE|os.O_APPEND, 0644)
if err != nil {
return nil, err
}
return &fileLogger{f: f}, nil
}使用时直接调用对应函数，按需传参，不用维护工厂实例状态：
logger, _ := NewFileLogger("/tmp/app.log")
// 或
logger := NewConsoleLogger()什么时候需要“工厂参数化”
当创建逻辑需要动态决策（比如根据配置选实现），才引入一个统一入口函数，但仍是函数，不是 struct：
- 参数通常是配置项（
string,struct,map[string]string），不是“产品类型枚举” - 返回值是接口，错误用
error显式表达失败 - 避免用
switch硬编码所有类型——优先用注册表（map[string]func() T）或选项函数（Option模式）扩展
例如注册式工厂：
var logFactories = make(map[string]func(map[string]string) (Logger, error))
<p>func RegisterLogger(name string, f func(map[string]string) (Logger, error)) {
logFactories[name] = f
}</p><p>func NewLogger(kind string, cfg map[string]string) (Logger, error) {
f, ok := logFactories[kind]
if !ok {
return nil, fmt.Errorf("unknown logger kind: %s", kind)
}
return f(cfg)
}容易踩的坑
常见反模式包括：
- 写一个带
Create()方法的LoggerFactorystruct，还要初始化它——纯属冗余 - 让工厂函数返回
interface{}再强制类型断言，破坏静态类型检查 - 在工厂里做 heavy 初始化（如连接数据库），却不暴露 error，导致 panic 或静默失败
- 把配置解析、校验、资源分配全塞进工厂函数，导致难以单元测试
真正该关注的是：接口是否正交、构造函数是否幂等、错误是否可预期、依赖是否显式传入。Go 的工厂，本质就是「干净的、有类型的、可测试的构造函数」。
