不用new或字面量创建对象是为了避免强耦合，工厂方法通过返回接口解耦“谁来造”和“造什么”，适合单一产品族变化；抽象工厂则用于创建相互关联的对象族，保证风格一致。
为什么不用 new 或字面量直接创建对象？
硬编码 &MyStruct{} 或 new(MyStruct) 会让调用方和具体类型强耦合。一旦要切换实现（比如从 MySQLUserRepo 换成 PostgresUserRepo），所有创建点都得改——这不是扩展，是修补。工厂方法和抽象工厂的本质，是把“谁来造”和“造什么”解耦，让新增类型不碰旧代码。
工厂方法：用函数返回接口，隐藏具体构造逻辑
适合单一产品族、但具体类型可能变化的场景（比如日志输出目标：文件 / 控制台 / 网络）。关键不是写个叫“Factory”的结构体，而是定义一个返回接口的函数，并让不同实现各自注册或导出自己的构造函数。
-
Logger接口统一行为，各实现（FileLogger、ConsoleLogger）只管自己初始化细节 - 不暴露
FileLogger{...}字面量，而是提供NewFileLogger(path string) Logger - 调用方只依赖
Logger接口和构造函数，不 import 具体实现包（可配合接口定义放在独立pkg/log包）
type Logger interface {
Log(msg string)
}
func NewFileLogger(path string) Logger {
return &FileLogger{path: path}
}
func NewConsoleLogger() Logger {
return &ConsoleLogger{}
}
抽象工厂：一组相关对象的创建契约
当系统需要创建多个**相互关联**的对象（如一套 UI 组件：Button + Checkbox + Dialog），且需保证风格一致（Windows 风格 vs macOS 风格），就该用抽象工厂。Go 没有抽象类，所以用接口定义“工厂能力”，再由具体工厂实现它。
- 抽象工厂接口（
GUIFactory）声明所有创建方法，但不实现 - 每个具体工厂（
WindowsFactory、MacFactory）返回对应平台的一组组件实例 - 客户端代码只接收
GUIFactory接口，完全不知道背后是 Windows 还是 Mac 实现 - 新增平台只需加新工厂结构体和实现，不改已有客户端逻辑
type Button interface{ Render() }
type Checkbox interface{ Render() }
type GUIFactory interface {
CreateButton() Button
CreateCheckbox() Checkbox
}
type WindowsFactory struct{}
func (w WindowsFactory) CreateButton() Button { return &WindowsButton{} }
func (w WindowsFactory) CreateCheckbox() Checkbox { return &WindowsCheckbox{} }
type MacFactory struct{}
func (m MacFactory) CreateButton() Button { return &MacButton{} }
func (m MacFactory) CreateCheckbox() Checkbox { return &MacCheckbox{} }
容易踩的坑：别把工厂变成全局状态或过度设计
工厂本身不该持有运行时状态（比如缓存一堆已创建对象），除非明确需要对象复用（这时应考虑 sync.Pool 而非工厂内部 map）。更常见的错误是过早抽象：只有两个实现时，硬套抽象工厂反而增加调用链和包依赖。先用简单工厂函数（func NewXxx(...) Interface），等第三个变体出现、且它们明显属于同一维度（数据库驱动、加密算法、序列化格式），再提取公共工厂接口。
立即学习“go语言免费学习笔记（深入）”；
接口命名别带 “Factory” 后缀（如 LoggerFactory），Go 社区习惯用功能描述（Logger）或动词（NewLogger 是函数名，不是类型）。真正难的是判断“何时抽象”——这取决于变化频率和团队对扩展点的共识，而不是模式名称本身。
