本文介绍一种简洁、可读性强且符合 go 语言惯用法的重构方案，通过封装带重试机制的连接函数，消除 nsq 生产者与消费者初始化中高度相似的循环重试逻辑，避免过度设计，兼顾清晰性与可维护性。
本文介绍一种简洁、可读性强且符合 go 语言惯用法的重构方案，通过封装带重试机制的连接函数，消除 nsq 生产者与消费者初始化中高度相似的循环重试逻辑，避免过度设计，兼顾清晰性与可维护性。
在分布式系统开发中，面对多个候选地址（如 NSQD 节点 IP 列表）进行连接尝试是常见需求：需按序遍历，成功即止，失败则继续下一项。若将该逻辑直接内联于多处业务代码中（如创建 nsq.Producer 和调用 consumer.ConnectToNSQD()），虽仅几行，却构成典型的「几乎重复」（Almost Repeating Myself）代码异味——它不满足泛型或复杂模式匹配的抽象门槛，但重复本身已损害可读性与后续演进（如增加超时、退避、日志、指标等）。
此时，最务实的重构不是引入泛型、反射或通用重试器，而是提取语义明确的封装函数。其核心原则是：让 API 的形状反映问题的本质，而非迁就某类“复用技术”。以下为推荐实现：
package main
import "github.com/nsqio/go-nsq"
// NewProducer 创建 NSQ 生产者，按顺序尝试提供的地址列表，任一成功即返回。
// 若地址列表为空，将尝试空字符串地址（触发库默认行为，便于测试）。
func NewProducer(addrs []string, config *nsq.Config) (producer *nsq.Producer, err error) {
if len(addrs) == 0 {
addrs = []string{""}
}
for _, addr := range addrs {
producer, err = nsq.NewProducer(addr, config)
if err == nil {
return // 成功，立即返回
}
}
return // 全部失败，返回最后一个错误
}
// ConnectToNSQD 尝试将 Consumer 连接到地址列表中的任一 NSQD 实例。
// 行为同 NewProducer：顺序尝试，成功即止。
func ConnectToNSQD(c *nsq.Consumer, addrs []string) (err error) {
if len(addrs) == 0 {
addrs = []string{""}
}
for _, addr := range addrs {
err = c.ConnectToNSQD(addr)
if err == nil {
return
}
}
return
}
使用时，业务代码变得极其清晰：
// 初始化 Producer
producer, err := NewProducer([]string{"10.0.1.1:4150", "10.0.1.2:4150"}, nsq.NewConfig())
if err != nil {
log.Fatal("failed to create producer:", err)
}
// 初始化 Consumer
consumer, _ := nsq.NewConsumer("topic", "channel", nsq.NewConfig())
if err := ConnectToNSQD(consumer, []string{"10.0.1.1:4150", "10.0.1.2:4150"}); err != nil {
log.Fatal("failed to connect consumer:", err)
}
✅ 关键优势：
- 零抽象泄漏：函数名直述意图（NewProducer、ConnectToNSQD），调用方无需理解底层重试机制；
- 错误语义清晰：返回最后一个失败错误，符合 Go 错误处理惯例，便于上层判断根本原因；
- 空列表安全：内置兜底逻辑，避免 panic 或未定义行为；
- 易于增强：后续如需添加连接超时、指数退避、健康检查或 Prometheus 指标，只需修改对应函数内部，调用方完全无感。
⚠️ 注意事项：
- 避免强行统一为单一泛型函数（如 RetryConnect[T any](fn func(string) (T, error), addrs []string)），这会模糊语义、增加心智负担，且无法适配不同函数签名（有返回值 vs 无返回值）；
- 不建议使用回调闭包封装，因 Go 中闭包易导致意外变量捕获，且不如具名函数直观；
- 若未来重试策略显著差异化（如 Producer 需重试 + 降级，Consumer 需重试 + 订阅恢复），应拆分为独立策略函数，而非强求统一接口。
总结：解决「几乎重复」的关键，在于识别出 值得封装的稳定契约（这里是「按序重试地址列表直至成功」），并以符合领域语义的具名函数落地。它不炫技，却精准克制，是 Go 工程实践中「简单优于通用」哲学的典范实践。
