不用if-else创建消息发送器，因违反开闭原则且易出错；工厂方法将创建逻辑交由子类实现，客户端仅依赖接口，支持多通道扩展与配置驱动。
为什么不用 if-else 创建消息发送器？
因为每次加一种新通道（比如钉钉、企业微信），就得改业务代码里的判断分支，一动就容易出错，还违反开闭原则。工厂方法把“创建谁”这个决定权交给子类，客户端只依赖接口，不碰具体类型。
常见错误现象：MessageSender sender = new EmailSender() 这种硬编码写法在通知渠道变多后会迅速失控；更糟的是，有人把所有 NewEmailSender、NewSMSSender 全塞进一个大函数里，还加了 switch，结果测试覆盖不到某条分支，线上发错渠道。
- 使用场景：需要支持邮件、短信、站内信等多通道，且未来可能新增飞书或 WhatsApp
- 参数差异：不同通道初始化依赖不同——邮件要
smtpServer和认证信息，短信要accessKey和签名模板 ID - 性能影响：工厂方法本身无额外开销，但若子类构造逻辑重（如加载配置、连接池预热），需考虑延迟初始化或缓存实例
怎么定义工厂接口和具体实现？
核心是抽象出一个创建接口，让每个通道自己决定怎么造自己的发送器。不是“工厂造产品”，而是“工厂接口 + 子类实现”组合成可插拔的创建点。
示例中，MessageSenderFactory 接口只有一个方法：Create() MessageSender；EmailSenderFactory 实现它时，内部 new 一个带 smtpServer 的 EmailSender；SMSFactory 则注入 client 和 templateID。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 别把工厂做成单例——除非你确定所有实例共享同一套配置；多数情况下，每个通道应有独立工厂实例
- 工厂方法返回的必须是接口类型（如
MessageSender），不能是具体结构体，否则又绕回去了 - 如果初始化需要上下文（如从配置中心拉取参数），建议工厂结构体里嵌入
config.Config或用函数选项模式传参
如何与配置中心/依赖注入结合？
硬编码工厂实例等于把渠道开关写死。真实项目里，哪个通道启用、用哪套 SMTP 地址、是否开启重试，都该来自外部配置。
典型做法：启动时读 app.yaml 或环境变量，根据 notification.channels.email.enabled: true 动态注册对应工厂；再把工厂实例注入到 NotificationService 中。Spring Boot 风格的自动装配在 Go 里靠 wire 或 fx 实现，但哪怕手写，也只需一个 map[string]MessageSenderFactory。
- 容易踩的坑：配置项名不统一，比如邮件用
email.host，短信却叫sms.api_url，导致工厂初始化时字段映射错乱 - 兼容性注意：配置中心变更后，工厂实例不能热替换——得重启或设计 reload hook，否则新配置不会生效
- 测试友好性：单元测试时，直接 new 一个 mock 工厂传进去，完全绕过配置解析逻辑
为什么说工厂方法只是起点，不是终点？
它只解决“创建谁”的问题，不解决“何时发”“发给谁”“失败怎么兜底”。见过太多人以为实现了工厂方法就完成了通知系统，结果发现没做限流，短信 API 被打挂；或者没加 trace ID，出问题根本查不到是哪个用户、哪条订单触发的。
真正落地时，工厂方法必须嵌入更大流程：事件驱动的调度层决定触发时机，规则引擎匹配模板和通道，投递层调用工厂拿到的 MessageSender 实例，最后由统一失败队列接管重试。漏掉任意一环，工厂造得再漂亮也没用。
