Go中应使用工厂函数而非new()初始化结构体，因其可校验字段、隐藏内部实现、统一内存管理并支持后续扩展；工厂函数应返回指针、参数用选项模式、避免全局单例，并仅用于需控制创建逻辑的结构体。
为什么不用 new() 而要用工厂函数封装结构体初始化
Go 没有构造函数，但直接暴露结构体字段 + new() 或字面量初始化容易破坏封装、绕过校验、导致零值误用。比如 User{} 会生成一个 ID=0, Name="" 的非法实例，后续调用可能 panic。
- 工厂函数能强制校验必要字段（如非空
Name、有效ID） - 隐藏内部字段（如把
passwordHash设为小写，仅通过工厂注入） - 统一控制内存分配方式（例如复用对象池，避免高频创建）
- 便于后期替换实现（比如从内存版切换到 DB 加载版，调用方完全无感）
NewUser() 这类工厂函数该怎么设计参数和返回值
工厂函数名通常以 New 开头，返回指针（*User），不返回错误的场景下，应确保初始化一定成功；若涉及外部依赖或校验失败可能，必须返回 error。
- 参数优先用具名字段结构体（
func NewUser(opts UserOptions)），避免长参数列表难以维护 - 不要接受裸指针或接口作为必填参数——这会让调用方过早关心实现细节
- 如果结构体有可选配置，用函数式选项（Functional Options）比布尔标记更清晰：
NewUser(WithRole("admin"), WithTimeout(30)) - 返回值永远用指针：值类型返回会触发复制，且无法满足接口赋值常见需求（如
io.Writer要求指针接收者）
type UserOptions struct {
Name string
Email string
}
func NewUser(opts UserOptions) (*User, error) {
if opts.Name == "" {
return nil, errors.New("Name is required")
}
return &User{
ID: nextID(),
Name: opts.Name,
Email: opts.Email,
}, nil
}
工厂模式在 Go 里和接口组合时最容易踩的坑
很多人以为“定义个 UserFactory 接口就叫工厂模式”，结果发现根本没法测试或替换——因为工厂本身成了新依赖源，且常被全局变量导出，导致单元测试难隔离。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 别写
var DefaultUserFactory UserFactory = &userFactoryImpl{}这种全局单例，它让依赖隐式化、无法 mock - 工厂实例应作为依赖注入进业务逻辑（如传入 service 构造函数），而不是在函数内直接调用
userfactory.NewUser() - 接口定义要窄：只暴露
Create() (interface{}, error)不够，应明确返回具体类型（Create() (*User, error)），否则失去类型安全 - 注意循环导入：工厂若依赖 DAO 层，而 DAO 又依赖模型，模型又 import 工厂 —— 这时得把工厂移到单独的
factory/包，并只 import 模型定义
什么时候该放弃工厂，直接用结构体字面量
不是所有结构体都需要工厂。简单、无状态、无校验、无生命周期管理的数据载体（DTO、配置项、请求参数），硬套工厂反而增加认知负担。
立即学习“go语言免费学习笔记（深入）”；
- 纯数据结构（如
type Config struct { Port int; Host string }）直接Config{Port: 8080}更直观 - 测试中构造 fixture 实例，用字面量比调工厂更轻量、更易读
- 性能敏感路径（如每秒百万级日志结构体创建），工厂函数调用开销虽小，但函数跳转 + 参数拷贝仍比字面量略重
- 当结构体字段全公开、无不变约束、也不打算未来加逻辑时，工厂只是冗余封装
真正需要工厂的，是那些你希望控制“怎么诞生”“能否诞生”“诞生后是否合法”的结构体——比如连接池中的 *DBConn、带上下文绑定的 *HTTPClient、或需加密初始化的 *Token。
