抽象工厂接口方法必须返回接口类型而非具体结构体，以确保调用方不依赖实现；工厂本身也应作为依赖注入，避免硬编码和违反开闭原则。
抽象工厂接口定义必须返回接口类型，不能返回具体结构体
Go 没有传统面向对象的 abstract class 或 interface implementation 强制机制，但抽象工厂的核心契约在于：工厂方法返回的是抽象（即 interface{}），而非具体类型。如果返回 *MySQLConnection 这类具体指针，调用方就直接依赖了实现，工厂的解耦意义就失效了。
常见错误是定义工厂函数返回具体类型：
func NewMySQLFactory() *MySQLFactory { ... } // ❌ 工厂本身也不该暴露具体类型
func (f *MySQLFactory) CreateConnection() *MySQLConnection { ... } // ❌ 返回具体结构体
正确做法是先定义统一行为接口：
type Connection interface {
Connect() error
Close() error
}
type Command interface {
Execute(sql string) error
}
type Factory interface {
CreateConnection() Connection
CreateCommand() Command
}
然后让每个具体工厂实现 Factory 接口，且所有方法返回对应接口类型 —— 这样上层代码只依赖 Factory 和 Connection 等接口，完全不知道 MySQL 或 PostgreSQL 的存在。
具体工厂需按环境/配置动态注册，避免硬编码 switch
很多初学者会写一个巨型 switch dbType 函数来返回不同工厂，这导致新增数据库类型就得改核心逻辑，违反开闭原则。更合理的方式是用 map 注册 + 配置驱动。
- 定义全局注册表：
var factories = make(map[string]Factory) - 为每种数据库实现具体工厂，并在
init()中注册：factories["mysql"] = &MySQLFactory{} - 运行时根据配置（如
os.Getenv("DB_DRIVER")）查找：f := factories[driver]，查不到就 panic 或返回默认
这样新增 SQLite 支持，只需加一个 SQLiteFactory 实现和一行 init() 注册，主流程代码零修改。
注意 Go 的值语义对工厂返回值的影响
Go 中接口变量底层存储的是（动态类型，动态值）对。如果工厂方法返回的是值类型（如 func() Connection { return MySQLConnection{} }），那每次调用都产生新副本；若返回指针（&MySQLConnection{}），则共享状态可能引发并发问题（比如连接池误共享）。
实际中应遵循以下原则：
-
Connection类型通常需要维护状态（如 net.Conn、连接池句柄），必须返回指针：return &MySQLConnection{...} -
Command如果是无状态的执行器（只封装 SQL 和参数），可返回值类型以避免逃逸，但多数场景仍建议指针——便于后续扩展上下文或日志字段 - 所有工厂方法返回的接口实例，其底层具体类型必须实现全部接口方法，否则运行时报
panic: interface conversion
测试抽象工厂时要 mock 具体实现，而非工厂本身
单元测试重点不是验证 MySQLFactory 是否返回了 *MySQLConnection，而是验证使用 Factory 接口的业务代码能否正常工作。因此应：
- 为测试编写一个
FakeFactory，它返回FakeConnection和FakeCommand（都实现对应接口） - 在测试中注入
FakeFactory，断言业务逻辑是否按预期调用了Connect()、Execute()等方法 - 不要在测试里 import
_ "yourapp/factory/mysql"—— 这会让测试依赖具体实现，失去抽象价值
真正的集成测试才需要启动真实 MySQL 容器并用 MySQLFactory 验证端到端行为。
抽象工厂在 Go 里不是靠语法强制，而是靠接口设计纪律和依赖注入习惯来落地。最容易被忽略的一点是：工厂本身也应作为依赖传入业务模块，而不是在函数内部直接调用 NewMySQLFactory() —— 否则测试时无法替换，抽象就形同虚设。
