简单工厂是用单个函数根据参数创建不同具体类型对象的封装手段，如NewLogger(type string) Logger；抽象工厂则是GoF模式，通过定义工厂接口及其实现来创建一族相关对象，如DBFactory接口及MySQLFactory实现。
简单工厂用一个函数创建多种类型实例
简单工厂不是 GoF 23 种设计模式之一，而是常见封装手段：用单个函数（通常是 NewXXX 或 Create）根据参数返回不同具体类型的对象。它不强调接口抽象，重点是“隐藏构造细节”。
典型场景：解析不同格式的配置文件、创建不同数据库驱动连接、生成不同日志输出器。
- 所有具体类型需实现同一接口（如
Logger），但工厂本身不依赖该接口的多态扩展 - 新增类型需修改工厂函数逻辑，违反开闭原则
- 没有“工厂类”，通常就是一个包级函数，例如
log.NewLogger(type string) Logger - 无法应对“一族相关对象”的创建需求（比如 MySQL 连接 + MySQL 事务 + MySQL 语句预编译器）
func NewLogger(typ string) Logger {
switch typ {
case "file":
return &FileLogger{}
case "console":
return &ConsoleLogger{}
default:
return &NullLogger{}
}
}
抽象工厂必须定义工厂接口并为每族产品提供实现
抽象工厂是 GoF 模式，核心是定义一个创建一族相关或相互依赖对象的接口（Factory），再为每种产品族提供具体工厂实现（如 MySQLFactory、PostgresFactory）。它解决的是“多系列平行类簇”的创建问题。
典型场景：跨数据库适配（连接、事务、语句）、UI 组件库适配（按钮、输入框、下拉框的不同风格实现）。
立即学习“go语言免费学习笔记（深入）”；
- 必须先定义产品接口族（如
Connection、Transaction、Statement）和工厂接口（DBFactory） - 每个具体工厂（
MySQLFactory）实现工厂接口，返回对应系列的具体类型 - 客户端只依赖工厂接口和产品接口，完全解耦具体实现
- 新增产品族只需添加新工厂实现，不改现有代码；但新增产品类型（如加一个
Migration）需修改所有工厂接口和实现，代价大
type DBFactory interface {
CreateConnection() Connection
CreateTransaction() Transaction
}
type MySQLFactory struct{}
func (m MySQLFactory) CreateConnection() Connection {
return &MySQLConnection{}
}
func (m MySQLFactory) CreateTransaction() Transaction {
return &MySQLTransaction{}
}
Go 中抽象工厂常被接口组合+依赖注入替代
Go 没有类继承，也不鼓励复杂工厂层级。多数真实项目中，抽象工厂的“一族对象”往往通过结构体字段组合接口来表达，工厂逻辑则退化为构造函数或 DI 容器注册。
-
MySQLClient结构体直接持有Connection、Transaction等接口字段，由调用方传入（显式依赖） - 使用 Wire / Dig 等 DI 工具时，“工厂”变成 provider 函数，按需绑定一组接口到具体实现
- 若硬要模拟抽象工厂，Go 的
interface{}或泛型（Go 1.18+）可减少重复，但会牺牲类型安全或增加泛型约束复杂度 - 简单工厂在 Go 中更自然——因为 Go 偏好小接口、短函数、显式构造，
NewXXX()就是事实标准
错误理解：把 newXXX() 当成抽象工厂
常见误区是认为 json.NewDecoder(r io.Reader) 或 http.NewServeMux() 是抽象工厂——它们只是带参数的构造函数，返回单一类型，不涉及“一族对象”或“可替换实现族”。
- 抽象工厂的关键标志是：存在多个并列的产品接口 + 一个能同时创建它们的工厂接口
- 如果只有一个返回类型，哪怕参数是
string或int，也只是简单工厂（甚至不算模式，只是封装） - Go 标准库几乎不用抽象工厂；
database/sql的驱动注册机制接近，但靠的是全局 map +sql.Open()查表，不是接口实现族
Transaction 必须来自同一个 Connection，这需要工厂保证内部状态关联，而不仅仅是返回独立实例。 
