工厂模式与包初始化结合设计思路

在 Go 中设计工厂模式时，最易被忽视却至关重要的问题并非实现细节，而是注册时机与调用安全性的精准对齐：因 Go 的包初始化机制导致未显式导入的包其 `init()` 不执行，常引发“注册丢失、返回 nil 或 panic”；并发注册易触发竞态，需用 `sync.RWMutex` 保护注册表而非 `sync.Map`；返回具体类型会破坏抽象与扩展性，应统一返回接口并延迟构造；而裸包变量式工厂更暗藏初始化顺序陷阱，须通过带校验的闭包、`sync.Once` 或显式初始化强制约束生命周期——真正决定系统健壮性的，从来不是工厂怎么造对象，而是谁在何时把“造物主”请上台。

Go 包里用 init() 做工厂注册，为什么总漏掉某个实现？

因为 init() 只在包被导入时触发，而 Go 的 import 路径去重机制会让未显式引用的包不执行 init() —— 即便它内部调用了 registerFactory()。

• 常见错误现象：NewService() 返回 nil 或 panic “unknown type”，但代码里明明写了 init() { register("mysql", newMysqlClient) }
• 使用场景：插件式客户端（如不同数据库驱动）、日志后端、序列化格式注册
• 根本原因：那个含 init() 的包没被任何地方 import，编译器直接丢弃了它
• 实操建议：在主模块的 main.go 或入口包里加一行 _ "github.com/xxx/mysql"，确保包加载

用函数变量代替 init() 注册，怎么避免竞态？

把工厂注册逻辑从 init() 搬到显式函数（比如 RegisterClient(name string, fn func() Client)），能控制时机，但并发调用时可能 panic。

• 常见错误现象：fatal error: concurrent map writes，因为多个 goroutine 同时调 RegisterClient
• 参数差异：sync.Map 不适合做注册表——它不支持遍历；用 map + sync.RWMutex 更稳妥
• 性能影响：读多写少场景下，RWMutex 的读锁几乎无开销；注册只在启动期发生，写锁成本可忽略
• 实操建议：注册表定义为 var registry = struct { mu sync.RWMutex; m map[string]func() Client }{m: make(map[string]func() Client)}

为什么 func New() *T 不该直接返回具体类型？

工厂函数返回具体类型（比如 func NewMySQL() *MySQLClient）会破坏抽象，让调用方感知实现细节，也阻碍运行时切换。

• 使用场景：配置驱动初始化（driver: "postgres" → 自动选对应 client）
• 容易踩的坑：用 switch cfg.Driver { case "mysql": return &MySQLClient{} } 写死在调用侧，导致每加一个驱动就要改此处
• 实操建议：统一用接口返回，注册时存构造函数，使用时查表调用：if ctor, ok := registry.m[cfg.Driver]; ok { return ctor() }
• 兼容性影响：返回接口类型（如 Client）后，后续新增驱动无需改旧调用代码

包级变量 + 工厂函数，如何防止未初始化就调用？

把工厂函数挂成包级变量（如 var NewClient func() Client），再在 init() 里赋值，看似简洁，但极易在 init() 执行前就被其他包访问。

• 常见错误现象：程序启动即 panic，堆栈指向某处调了 pkg.NewClient()，但此时 NewClient == nil
• 根本原因：Go 初始化顺序按 import 图拓扑排序，A 依赖 B，B 依赖 C，但 A 的 init() 可能在 C 的 init() 前执行
• 实操建议：放弃裸变量，改用带检查的闭包：var NewClient = func() Client { if factory == nil { panic("factory not registered") }; return factory() }
• 更稳做法：用 sync.Once 延迟初始化，或干脆要求使用者显式调 pkg.MustInit()

好了，本文到此结束，带大家了解了《工厂模式与包初始化结合设计思路》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多Golang知识！