工厂函数应封装构造逻辑，校验参数、处理I/O错误、返回可运行实例，避免调用方依赖具体类型；NewXXX命名是Go社区惯例；需动态切换实现时才引入工厂接口；工厂须纯函数化，不读全局状态。
为什么不用 new 而要写工厂函数
直接调用 new 或字面量初始化结构体，会让调用方强依赖具体类型和构造细节。一旦类型内部字段变更、需要校验、或后续要替换为带连接池的实例，所有调用点都得改。工厂函数把“怎么造”收口到一处，调用方只关心“要什么”，不关心“怎么来”。
常见错误是把工厂写成简单封装：比如只做 return &MyStruct{}，没加参数校验、没处理资源初始化失败、也没预留扩展接口。这种写法看似解耦，实则只是换了个地方写 new。
- 必须校验必要参数（如
url不能为空） - 若涉及 I/O（如打开文件、建立 DB 连接），应在工厂内完成并返回 error
- 避免在工厂里写业务逻辑，只专注“创建可运行实例”这一件事
func NewXXX(...) 是最实用的工厂形式
Go 社区广泛接受以 New 开头的首字母大写的函数作为导出工厂，比如 NewHTTPClient、NewRepository。它轻量、无接口抽象负担，适合大多数场景。相比 Go 语言中常见的接口+结构体组合模式，这种函数工厂更直观，也更容易测试。
注意命名一致性：如果类型叫 Cache，工厂就叫 NewCache；如果类型是 redisCache（小写首字母，未导出），工厂仍应叫 NewCache 并返回导出接口或指针。
立即学习“go语言免费学习笔记（深入）”；
func NewCache(addr string, timeout time.Duration) (*Cache, error) {
if addr == "" {
return nil, errors.New("addr cannot be empty")
}
c := &Cache{addr: addr, timeout: timeout}
if err := c.connect(); err != nil {
return nil, fmt.Errorf("failed to connect: %w", err)
}
return c, nil
}
什么时候该上接口+工厂接口，而不是单个函数
当系统需要支持多种实现且调用方需动态切换时，比如日志后端支持 FileLogger 和 SentryLogger，且配置决定用哪一种——这时单个 NewLogger 函数就不够用了，得靠工厂接口统一创建入口。
但别过早抽象：先写死一个实现 + NewXXX 函数，等第二个实现出现、且调用方已显式依赖接口时，再提取工厂接口。否则容易陷入“为设计而设计”的陷阱。
- 工厂接口定义通常只需一个
Create()方法，返回公共接口 - 每个实现配一个具体工厂类型，比如
FileLoggerFactory、SentryLoggerFactory - 避免让工厂接口本身依赖具体实现，否则又绕回去了
工厂里别偷偷做单例或全局状态
工厂函数默认应每次返回新实例。如果内部缓存了对象（比如用 sync.Once 初始化全局 client），必须明确命名，例如 SingletonHTTPClient 或 DefaultDB，否则使用者会误以为每次调用都是独立实例，导致并发问题或测试隔离失败。
尤其要注意：测试时如果工厂返回的是共享实例，多个 test case 可能互相干扰。真正需要复用时，应由上层容器（如应用启动时）控制生命周期，而非藏在工厂里。
最容易被忽略的一点：工厂函数的参数应当完全决定输出结果。如果它读了环境变量、配置文件或全局变量，那就不是纯工厂，而是配置加载器+工厂混合体——这种耦合会极大增加单元测试难度。
