Go语言工厂模式通过接口+工厂函数实现，而非类继承；工厂函数返回接口类型实例，集中管理创建逻辑，提升可维护性、可测试性与扩展性。
Go 语言没有类和继承，所以工厂模式不是靠“抽象基类 + 子类实现”来落地的，而是靠接口 + 函数返回具体结构体实例来完成。核心在于：用一个函数封装创建逻辑，返回满足某接口的任意具体类型。
如何定义工厂函数与产品接口
先定义统一行为契约（接口），再让不同结构体实现它，最后由工厂函数根据参数决定返回哪个结构体的指针。注意：工厂函数返回的是接口类型，不是具体类型，否则就失去多态意义。
- 接口应只包含业务必需的方法，避免过度设计
- 工厂函数参数建议用字符串或枚举（
int常量）控制分支，避免硬编码类型名 - 返回值必须是接口类型，例如
Shape，而不是*Circle
type Shape interface {
Area() float64
}
<p>type Circle struct {
Radius float64
}
func (c <em>Circle) Area() float64 { return 3.14 </em> c.Radius * c.Radius }</p><p>type Rectangle struct {
Width, Height float64
}
func (r <em>Rectangle) Area() float64 { return r.Width </em> r.Height }</p><p>func NewShape(shapeType string) Shape {
switch shapeType {
case "circle":
return &Circle{Radius: 1.0}
case "rectangle":
return &Rectangle{Width: 2.0, Height: 3.0}
default:
return nil
}
}为什么不用 new(Circle) 直接创建而要封装成工厂函数
直接调用 new 或字面量构造会把创建逻辑散落在业务代码各处，一旦新增类型或修改初始化参数（比如所有 Circle 都要加默认颜色字段），就得全局搜索修改。工厂函数集中了这些变化点。
- 初始化逻辑可能依赖配置、环境变量或外部服务（如从 DB 查默认值），不能简单字面量初始化
- 某些结构体需要执行注册、缓存预热等副作用，工厂函数是唯一可控入口
- 测试时可轻松替换为 mock 实现（比如返回
&MockShape{}），而无需改业务代码
简单工厂 vs 抽象工厂：Go 里怎么选
Go 中几乎只用“简单工厂”（一个函数返回一种接口），因为“抽象工厂”本质是工厂的工厂，需要多个工厂接口+多个实现，反而增加冗余。除非你明确需要一组相关产品（如 LinuxButton + LinuxDialog 绑定创建），否则别强行套用。
立即学习“go语言免费学习笔记（深入）”；
- 简单工厂：用
func NewXXX(...) Interface即可，95% 场景够用 - 抽象工厂：定义工厂接口（如
UIFactory），再为不同平台实现（WindowsFactory、MacFactory），但 Go 中更常见的是用配置驱动（os.Getenv("OS")）在同一个工厂函数内分支 - 不要为工厂而工厂——如果只有 1 种实现且永不扩展，直接
&MyStruct{}更清晰
容易踩的坑：nil 指针、值接收器、包循环依赖
工厂函数返回结构体指针是常规做法，但如果结构体方法用了值接收器，又没注意接口实现是否完整，会导致运行时 panic；另外工厂函数若放在被创建类型所在包，容易引发 import 循环。
- 确保所有实现方法签名与接口完全一致（包括指针/值接收器）；
func (c Circle) Area()和func (c *Circle) Area()是两个不同实现 - 工厂函数建议放在独立包（如
factory或creator），或至少放在调用方所在包，避免shape包 import 自己 - 不要在工厂里做耗时操作（如 HTTP 请求），否则调用方无法控制超时；应把依赖注入进去，例如
NewShape(cfg Config, client HTTPClient)
工厂模式在 Go 里不是语法必需，而是组织创建逻辑的手段。真正关键的是：谁负责初始化、谁持有依赖、哪一层该知道具体类型——这些比“是不是模式”重要得多。
