本文介绍一种简洁、专业且符合 go 语言惯用法的方式，将“遍历 ip 列表并逐个尝试连接直至成功”的重复逻辑提取为独立函数，避免代码冗余，同时保持可读性与可维护性。
本文介绍一种简洁、专业且符合 go 语言惯用法的方式，将“遍历 ip 列表并逐个尝试连接直至成功”的重复逻辑提取为独立函数，避免代码冗余，同时保持可读性与可维护性。
在分布式系统或高可用服务中，客户端常需连接多个候选地址（如 NSQD 节点），并在首个可达地址上建立连接。若直接在业务逻辑中硬编码循环重试逻辑，会导致多处出现高度相似的结构——仅函数调用和错误判断细节不同。这种“几乎重复自己”（Almost Repeating Myself）的模式虽不构成严重坏味，但损害可维护性与一致性。
与其强行抽象为泛型工具或通用重试框架（易引入过度设计），不如针对具体问题提供语义清晰、职责单一的封装函数。以下是以 nsq 客户端为例的实践方案：
✅ 推荐做法：按用途封装，而非按结构抽象
为 nsq.Producer 和 nsq.Consumer 分别定义专用的重试构造函数，名称直指其行为意图：
package main
import "github.com/nsqio/go-nsq"
// NewProducer 尝试使用提供的地址列表创建 NSQ 生产者，
// 返回首个成功连接的实例及其错误（若全部失败则返回最后一个错误）。
func NewProducer(addrs []string, config *nsq.Config) (*nsq.Producer, error) {
if len(addrs) == 0 {
return nil, nsq.ErrInvalidAddress
}
var lastErr error
for _, addr := range addrs {
if addr == "" {
lastErr = nsq.ErrInvalidAddress
continue
}
p, err := nsq.NewProducer(addr, config)
if err == nil {
return p, nil // 成功即刻返回
}
lastErr = err
}
return nil, lastErr
}
// ConnectToNSQD 尝试将 Consumer 连接到地址列表中的任一 NSQD 实例，
// 成功后立即返回 nil 错误；全部失败则返回最后一个错误。
func ConnectToNSQD(c *nsq.Consumer, addrs []string) error {
if len(addrs) == 0 {
return nsq.ErrInvalidAddress
}
var lastErr error
for _, addr := range addrs {
if addr == "" {
lastErr = nsq.ErrInvalidAddress
continue
}
err := c.ConnectToNSQD(addr)
if err == nil {
return nil
}
lastErr = err
}
return lastErr
}
? 关键设计说明
- 语义优先命名：NewProducer 和 ConnectToNSQD 直接映射原始操作意图，调用方无需理解底层重试机制；
- 错误处理合理：空地址列表或全失败时返回明确错误（如 nsq.ErrInvalidAddress），而非静默忽略或 panic；
- 尽早返回：成功即刻退出循环，避免无谓遍历；
- 零侵入性：不修改原有 nsq 包接口，完全兼容现有代码；
- 可测试性强：每个函数职责单一，易于单元测试（例如模拟前 N−1 次失败、第 N 次成功）。
⚠️ 注意事项
- 避免盲目泛化为 RetryUntilSuccess(func() error) error 类型通用函数：它会模糊业务语义，降低可读性，并可能掩盖关键上下文（如是否需要返回构造对象、是否允许部分参数动态生成等）；
- 若未来需支持超时、指数退避或健康检查，应在该封装层内部演进，而非提前引入复杂配置参数；
- 对于非 nsq 场景（如 Redis、gRPC），应遵循相同原则——为每类资源创建专属重试构造器，而非堆砌通用工具箱。
通过这种“小而专”的封装策略，你既消除了重复代码，又未牺牲表达力与可维护性——这正是 Go 哲学所倡导的：用清晰的接口表达明确的意图，而非用抽象掩盖复杂性。
