Golang工厂模式实现多消息推送

本文深入探讨了在Go语言中如何通过工厂模式优雅实现多消息推送系统，直击传统if-else分支创建发送器所导致的违反开闭原则、易出错、难扩展等痛点；通过抽象工厂接口与通道专属实现的解耦设计，支持邮件、短信、站内信乃至飞书、WhatsApp等新渠道的零侵入扩展，同时兼顾配置驱动、依赖注入与性能考量；更关键的是，文章强调工厂方法并非银弹——它仅解决“创建谁”的问题，必须与事件调度、规则匹配、失败重试、链路追踪等环节协同，才能构建健壮可落地的全链路通知系统。

为什么不用 if-else 创建消息发送器？

因为每次加一种新通道（比如钉钉、企业微信），就得改业务代码里的判断分支，一动就容易出错，还违反开闭原则。工厂方法把“创建谁”这个决定权交给子类，客户端只依赖接口，不碰具体类型。

常见错误现象：MessageSender sender = new EmailSender() 这种硬编码写法在通知渠道变多后会迅速失控；更糟的是，有人把所有 NewEmailSender、NewSMSSender 全塞进一个大函数里，还加了 switch，结果测试覆盖不到某条分支，线上发错渠道。

• 使用场景：需要支持邮件、短信、站内信等多通道，且未来可能新增飞书或 WhatsApp
• 参数差异：不同通道初始化依赖不同——邮件要 smtpServer 和认证信息，短信要 accessKey 和签名模板 ID
• 性能影响：工厂方法本身无额外开销，但若子类构造逻辑重（如加载配置、连接池预热），需考虑延迟初始化或缓存实例

怎么定义工厂接口和具体实现？

核心是抽象出一个创建接口，让每个通道自己决定怎么造自己的发送器。不是“工厂造产品”，而是“工厂接口 + 子类实现”组合成可插拔的创建点。

示例中，MessageSenderFactory 接口只有一个方法：Create() MessageSender；EmailSenderFactory 实现它时，内部 new 一个带 smtpServer 的 EmailSender；SMSFactory 则注入 client 和 templateID。

• 别把工厂做成单例——除非你确定所有实例共享同一套配置；多数情况下，每个通道应有独立工厂实例
• 工厂方法返回的必须是接口类型（如 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 实例，最后由统一失败队列接管重试。漏掉任意一环，工厂造得再漂亮也没用。

到这里，我们也就讲完了《Golang工厂模式实现多消息推送》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！