Go embed 嵌入配置文件后如何安全热更新：fs.FS 读取与原子替换

服务第一次启动时，默认配置最好跟着 Go 二进制一起交付；运行中收到配置变更，又不能去修改只读的嵌入文件。一个稳妥的边界是：用 embed.FS 读取默认值，把外部更新写入临时文件，校验通过后用 os.Rename 替换正式文件，读取方通过 atomic.Value 看到完整版本。

把“默认值”和“运行时覆盖值”分成两条路径：默认值由 fs.ReadFile 读取，更新值先落临时文件并完成解析，最后再做原子替换，避免读到半截配置。

先把默认配置和运行时文件分开

项目目录里放一份 config/default.json，编译时通过 embed.FS 打进二进制。程序启动时先执行 fs.ReadFile(defaultFS, "config/default.json")，解析出一份可用配置；如果部署目录存在外部的 config/runtime.json，再按同一套校验规则读取它。

package config

import (
    "embed"
    "io/fs"
    "os"
    "path/filepath"
    "sync/atomic"
)

//go:embed config/default.json
var defaultFS embed.FS

func readDefault() ([]byte, error) {
    return fs.ReadFile(defaultFS, "config/default.json")
}

func readRuntime(path string) ([]byte, error) {
    return os.ReadFile(path)
}

这里的关键不是把两份文件合并得多复杂，而是定义优先级：外部文件可用时覆盖默认值，外部文件不存在或校验失败时继续使用上一份内存配置。默认文件不能被“热写回”，因为它属于编译产物。

用临时文件和 os.Rename 提交一次完整更新

更新接口收到新内容后，不要直接打开 config/runtime.json 截断写入。先在同一目录创建临时文件，写完后执行 JSON 解析和业务字段校验；全部通过后关闭文件，再调用 os.Rename(tempPath, targetPath)。同一文件系统内的替换不会把半截内容暴露给新的读取者。

func replaceConfig(target string, data []byte) error {
    dir := filepath.Dir(target)
    temp, err := os.CreateTemp(dir, ".runtime-*.tmp")
    if err != nil { return err }
    tempPath := temp.Name()
    defer os.Remove(tempPath)

    if _, err = temp.Write(data); err != nil { temp.Close(); return err }
    if err = validate(data); err != nil { temp.Close(); return err }
    if err = temp.Sync(); err != nil { temp.Close(); return err }
    if err = temp.Close(); err != nil { return err }
    return os.Rename(tempPath, target)
}

临时文件必须和目标文件处于同一目录，否则跨文件系统时 os.Rename 可能失败。defer os.Remove 用来清理写入失败后遗留的临时文件；替换成功后，临时路径已经不存在，清理动作不会影响新文件。

用 atomic.Value 发布内存中的当前版本

文件替换解决了磁盘上的半写问题，但请求处理函数如果每次都重新读文件，仍会把磁盘 I/O 带进主链路。可以在加载成功后把完整结构放入 atomic.Value，读请求只取当前快照；更新失败则不调用 Store，旧配置自然继续生效。

var current atomic.Value // stores *Config

func Load() *Config {
    return current.Load().(*Config)
}

func Publish(next *Config) {
    current.Store(next)
}

所有存入的值必须是同一具体类型，例如始终存 *Config，不能第一次存结构体值、下一次又存指针。启动阶段还要先完成一次 Store，否则第一次 Load 会因没有值而出错。

发布前检查这几个边界

压测时重点观察的是更新失败后的行为：构造一个缺少必填字段的 JSON，确认接口返回校验错误，正式文件内容不变，随后请求仍读到旧版本。再并发执行读请求和更新请求，检查读到的每份配置是否都能通过完整校验，而不是出现零值字段。

常见问题

embed.FS 里的文件能在运行时直接修改吗？

不能。它是编译进二进制的只读文件系统，热更新应写到外部路径。

为什么临时文件要和目标文件放在同一目录？

这样可以保证 os.Rename 在同一文件系统内完成替换，避免跨挂载点导致重命名失败。

atomic.Value 能不能存不同类型的配置？

不能混用具体类型。固定存 *Config，并在首次读取前完成初始化。

小结

embed.FS 负责兜底，外部文件负责覆盖，os.Rename 负责提交，atomic.Value 负责把完整配置快照交给并发读请求。四者各自只做一件事，更新失败时旧版本仍然可用，这比给一个共享文件加大锁更容易验证。