Go 怎么热更新配置并让并发请求读取同一份快照

Go 服务要在不重启进程的情况下更新超时、开关或路由规则，最稳妥的做法不是让多个 goroutine 共同修改一个 Config，而是把配置构造成一次性快照：更新方先在局部变量中完成读取、校验和复制，再用 atomic.Value.Store 整份替换；请求方只用 Load 取当前快照。这样一次请求看到的是旧版本或新版本，不会看到“字段 A 已更新、字段 B 还没更新”的中间状态。

一、先把配置设计成可替换快照

先把“配置来源”和“并发共享位置”分开。文件、环境变量或远程配置中心负责产生候选值，AppConfig 负责承载一份完整结果，atomic.Value 只保存当前已发布的指针。请求处理器不参与更新，也不应该拿着指针去改规则表。

下面的结构故意把 Rules 作为 map 展示，因为它最容易暴露问题：如果更新线程直接对旧快照的 map 写入，即使外层指针的 Store 是原子的，读线程仍可能与写线程并发访问同一张 map。

二、用 Store 发布第一份配置

官方文档规定，Value 的零值在没有 Store 时 Load 返回 nil；一旦 Store，后续 Store 必须使用同一具体类型，而且 Value 第一次使用后不能复制。因此初始化不能省略，类型也不能一会儿存 AppConfig、一会儿存 *AppConfig。

package config

import (
    "fmt"
    "sync/atomic"
    "time"
)

type AppConfig struct {
    Timeout time.Duration
    Welcome string
    Rules   map[string]string
}

type Store struct {
    current atomic.Value // 始终存 *AppConfig
}

func cloneConfig(src AppConfig) *AppConfig {
    rules := make(map[string]string, len(src.Rules))
    for key, value := range src.Rules {
        rules[key] = value
    }
    return &AppConfig{
        Timeout: src.Timeout,
        Welcome: src.Welcome,
        Rules:   rules,
    }
}

func NewStore(initial AppConfig) *Store {
    s := &Store{}
    s.current.Store(cloneConfig(initial))
    return s
}

func (s *Store) Load() *AppConfig {
    return s.current.Load().(*AppConfig)
}

func (s *Store) Replace(next AppConfig) {
    s.current.Store(cloneConfig(next))
}

cloneConfig 的意义不在于让复制本身变成原子操作，而在于把复制过程放到尚未共享的局部数据上。只有复制完成后才 Store。若新配置校验失败，直接返回错误，不调用 Replace，旧快照仍可继续服务。

三、并发请求只 Load 不修改

请求路径只做一次 Load，然后在这次请求的生命周期内使用同一个指针。更新路径则读取新文件、解析并校验，再创建新的 AppConfig。两条路径之间共享的是 Value 中的指针，不共享正在构造的 map。

func handleRequest(store *Store, mode string) string {
    cfg := store.Load()
    if rule, ok := cfg.Rules[mode]; ok {
        return rule
    }
    return cfg.Welcome
}

func reload(store *Store, candidate AppConfig) error {
    if candidate.Timeout 

这里的关键是“先准备，后发布”：handleRequest 不写 Rules，reload 不拿当前 Load 出来的旧指针做原地修改。更新完成后，新请求会读取新快照，已经拿到旧快照的请求可以自然地把本次处理做完。

四、哪些场景不该用 atomic.Value

atomic.Value 适合“读多写少、整份替换”的配置，不适合把它当作一个万能并发 map。配置里的 map、slice、指针指向的对象只要在 Store 后继续修改，就可能重新引入数据竞争；需要原地增删、需要多个字段跨操作保持一致，或写入频率很高时，sync.RWMutex 往往更直接。

上线前可以逐项核对：初始化是否一定 Store 了非 nil 指针；所有 Store 是否都是 *AppConfig；map 和 slice 是否在发布前复制；请求方是否只读；更新失败是否保留旧值；Store 自身是否被放进不会复制的长期结构中。

相关问题

atomic.Value 第一次 Load 为什么得到 nil？

因为 Value 的零值尚未发布任何数据。先用合法的非 nil 值完成一次 Store，再让请求线程进入 Load。

能不能先 Store 一个 AppConfig，再 Store *AppConfig？

不能。两者是不同的具体类型，同一个 Value 混用会 panic；从初始化开始就统一成一种类型。

读到旧配置是不是更新失败？

不一定。已经开始处理的请求可能持有旧快照，这是快照模型的正常结果；应在下一次 Load 时确认新请求读到新版本。

依据：Go sync/atomic 官方文档。