Go结构体与指针【2】接收者应该怎么用

我看很多地方都鼓励使用结构体接收者呀，为什么这里不使用呢

这是一个非常好的观察。Go 确实鼓励使用结构体接收者（Method），但"什么时候用"取决于你把这个方法看作是"对象的行为"还是"对象的构造"。

在配置加载这个场景下，不建议使用接收者（尤其是指针接收者）主要有以下三个原因：

1. "先有鸡还是先有蛋"的悖论

在你原本的代码中：

复制代码

func (r *RedisConfig) Load() RedisConfig { ... }

这是一个指针接收者。这意味着在调用 Load 之前，你必须已经有一个 RedisConfig 的实例（哪怕是空值）。

语义矛盾： Load 的目的是为了"创建"或"填充"配置。如果我已经有一个对象了，再去调用它的方法返回一个新对象，这在逻辑上显得多余。
写法繁杂：导致你必须写成 redis := RedisConfig{}; conf = redis.Load()，多了一步无意义的实例化。

2. 区分"行为"与"工厂"

Go 的惯例是：

工厂函数（New/Load）：如果目的是从无到有创建一个结构体，应该使用普通的函数（通常叫 New... 或 Load...）。
- 例子： sql.Open(), http.NewRequest()。
方法（Method）：如果目的是对已经存在的数据进行操作或获取信息，才使用接收者。
- 例子： conf.GetAddr() 或 db.Query()。

3. 指针接收者的陷阱

你原来的 Load 方法使用的是 (r *RedisConfig)，但在方法体内部，你完全没有用到 r（没有 r.Host = ...），而是直接返回了一个新的结构体。

这违反了指针接收者的初衷：指针接收者通常是为了修改原对象的值。
如果你想用接收者且不打算修改原对象，应该用值接收者 (r RedisConfig)。但回到第一点，对于初始化逻辑，函数依然比方法更直接。

什么时候该用结构体接收者？

如果你希望配置具有"行为"，比如校验配置是否合法，这时候用接收者就非常完美：

复制代码

// 这是一个"行为"，校验已加载的数据，用接收者很合适
func (r *RedisConfig) Validate() error {
    if r.Port == 0 {
        return errors.New("redis port cannot be zero")
    }
    return nil
}

// 使用场景
cfg := config.LoadRedisConfig() // 函数负责创建
if err := cfg.Validate(); err != nil { // 方法负责校验行为
    log.Fatal(err)
}

总结建议

对于你的项目结构：

创建/加载：用 LoadRedisConfig() RedisConfig（普通函数）。
获取属性/处理逻辑：用 (c *Config) GetServerAddr() string（接收者方法）。

这样做你的 Config 包会非常清晰：函数负责"生孩子"，方法负责"教孩子干活"。