直接new struct不适合多变创建逻辑，因硬编码会导致if/else泛滥且新增类型需修改入口；工厂模式将实例化决策剥离，函数型工厂返回接口实现解耦，结构体工厂支持配置与依赖注入，但需注意指针接收者匹配及错误处理。
为什么直接 new struct 不适合多变的创建逻辑
当业务中需要根据参数动态决定创建哪种具体类型（比如不同支付方式：Alipay、WechatPay、BankTransfer），硬编码 &Payment{Type: "alipay"} 会快速导致 if/else 泛滥，且每新增一种类型都要改创建入口。工厂模式把“实例化谁”这个决策从调用方剥离，交给专门的工厂函数或结构体处理。
用函数型工厂实现最简解耦
Go 没有类继承，但函数是一等公民，用返回接口的工厂函数足够轻量。关键点在于：工厂不暴露具体类型，只返回统一接口；调用方完全不知道底层是哪个 struct。
type Payment interface {
Process(amount float64) error
}
type Alipay struct{}
func (a *Alipay) Process(amount float64) error {
// 实现
return nil
}
type WechatPay struct{}
func (w *WechatPay) Process(amount float64) error {
// 实现
return nil
}
// 工厂函数：输入类型名，输出 Payment 接口
func NewPayment(kind string) Payment {
switch kind {
case "alipay":
return &Alipay{}
case "wechat":
return &WechatPay{}
default:
return nil // 或 panic，视错误策略而定
}
}
- 调用方只需
NewPayment("alipay")，无需 import 具体实现包 - 新增支付方式时，只改工厂函数内部 switch，不碰已有调用代码
- 注意：返回
nil可能引发 panic，建议配合error返回或使用指针+ok 模式
用结构体工厂支持配置化与依赖注入
当创建对象需要传入配置（如 API key、超时时间）或依赖其他服务（如日志器、数据库连接），函数型工厂不够灵活。此时定义一个带字段的工厂结构体更清晰。
type PaymentFactory struct {
Logger *zap.Logger
Timeout time.Duration
}
func (f *PaymentFactory) New(kind string, config map[string]string) (Payment, error) {
switch kind {
case "alipay":
return &Alipay{
Key: config["key"],
Logger: f.Logger,
Timeout: f.Timeout,
}, nil
case "wechat":
return &WechatPay{
AppID: config["appid"],
Logger: f.Logger,
Timeout: f.Timeout,
}, nil
default:
return nil, fmt.Errorf("unknown payment kind: %s", kind)
}
}
- 工厂自身可携带共享依赖（
Logger、Timeout），避免每个创建都重复传参 -
config map[string]string提供扩展性，不同子类型按需解析自己关心的字段 - 返回
error而非nil，让调用方必须显式处理创建失败场景
工厂方法和接口组合容易被忽略的坑
Go 的接口是隐式实现，但工厂返回接口时，若忘记加 *（即返回值类型是 Alipay 而非 *Alipay），会导致方法集不匹配——因为只有指针才拥有接收者为指针的方法。
立即学习“go语言免费学习笔记（深入）”；
- 检查你的 struct 方法接收者：如果
Process是func (p *Alipay) Process(...)，那工厂必须返回&Alipay{}，不能是Alipay{} - 工厂函数签名别写成
func() *Payment—— 接口不能取地址，*Payment是非法类型 - 测试工厂时，别只测能否创建，要验证返回对象是否真能调用接口方法（尤其涉及嵌入字段或组合时）
工厂不是银弹。当类型分支极少（仅 2–3 种）、生命周期极短、或创建逻辑本身无状态时，直接 new 更直白。真正需要工厂的，是那些创建成本高、依赖复杂、或未来大概率要横向扩展的组件。
