工厂函数返回接口类型时，必须确保所有实现完整满足接口契约，否则编译失败；应先定义接口、用静态检查验证实现，稳定方法签名，避免硬编码和panic，合理注入依赖，并明确声明线程安全性。
工厂函数返回接口类型时，必须确保所有实现都满足接口契约
Go 没有传统面向对象的抽象类或继承语法，工厂模式依赖接口和具体结构体的组合。关键在于：工厂函数（如 NewPaymentProcessor）返回的是接口类型，而每个具体实现（如 AlipayProcessor、WechatProcessor）必须完整实现该接口的所有方法，否则编译失败。
- 常见错误是漏实现接口某个方法，报错类似：
cannot use &AlipayProcessor{} (type *AlipayProcessor) as type PaymentProcessor in return argument: *AlipayProcessor does not implement PaymentProcessor (missing Process method) - 推荐先定义接口，再写结构体，用
var _ PaymentProcessor = (*AlipayProcessor)(nil)在包初始化时做静态检查 - 接口方法签名要稳定——比如
Process(amount float64) error比Process(ctx context.Context, amount float64) (string, error)更易扩展；后者一旦加参数，所有实现都要改
使用字符串参数创建实例时，避免硬编码和无提示的 panic
很多初学者直接用 switch paymentType + return &AlipayProcessor{}，但没处理未知类型，导致运行时 panic。这不是“优雅降级”，而是隐藏缺陷。
- 不要用
panic("unknown type")，应返回(nil, fmt.Errorf("unsupported payment type: %s", paymentType)) - 把合法类型枚举为常量，例如：
const ( TypeAlipay = "alipay" ; TypeWechat = "wechat" )，避免散落的字符串字面量 - 若需支持动态注册（如插件式支付渠道），可用
map[string]func() PaymentProcessor，在init()中注册，工厂函数查表调用构造函数
结构体字段初始化不依赖工厂时，容易造成零值误用
工厂函数不只是 new 一个结构体，还要负责设置必要依赖。比如支付处理器需要配置项或客户端实例，如果只做 &AlipayProcessor{}，内部字段可能是零值，后续调用 Process() 时才 panic 或静默失败。
- 构造函数应接收必要依赖，例如：
func NewAlipayProcessor(conf *AlipayConfig, client *http.Client) PaymentProcessor - 工厂函数中统一传入共享依赖（如全局
http.DefaultClient或日志实例），避免各实现重复判断 - 若某字段可选，用指针或配置结构体封装，例如
Options struct { Timeout time.Duration; Logger *log.Logger }，再通过函数式选项模式传入
并发场景下，工厂返回的实例是否线程安全需明确声明
Go 的工厂模式常被用于生成 handler、client 等长生命周期对象。但没人会自动保证你的 *DBClient 或 *CacheManager 是并发安全的——这完全取决于你结构体里有没有未加锁的可变状态。
- 如果结构体含 map、slice、sync.WaitGroup 等非并发安全字段，且暴露了修改方法，那它就不是线程安全的；工厂函数无法改变这点
- 文档或注释里必须写明：“
AlipayProcessoris safe for concurrent use” 或 “not safe for concurrent use” - 更稳妥的做法是：让工厂返回不可变配置 + 并发安全的封装，例如用
sync.Pool缓存临时对象，或把状态外置到单独的 service 层
工厂模式在 Go 里本质是「解耦创建逻辑」，不是套设计模式帽子。最容易被忽略的，其实是接口定义粒度和错误处理路径——它们决定了后续每新增一个实现要改多少地方、出错时能不能快速定位。
