atomic.loadint64不能用于文件内容，因其仅作用于内存变量；真正的原子文件写入依赖os.rename的系统级原子性，而非go的atomic包。
Go 里没有“文件读写的原子操作”这个东西——atomic 包不处理 I/O，它只管内存里的整数、指针等基本类型的读写。所谓“原子文件写入”，靠的是操作系统层面的 rename 系统调用的原子性，不是 Go 语言层的 atomic 函数。
为什么 atomic.LoadInt64 不能用于文件内容
atomic 操作作用域仅限于进程内内存变量：atomic.LoadInt64 读的是一个 int64 变量的值，不是磁盘上某个文件的内容。文件 I/O 是系统调用，涉及缓冲、页缓存、磁盘队列等多层，Go 的 atomic 包对其完全无感知。
常见误解是以为“用了 atomic 就能安全读配置文件”，结果代码里还在 os.Open 后直接 json.Decode 到全局结构体——这和 atomic 毫无关系，照样有竞态或脏读风险。
真正需要保护的，是「配置数据在内存中的表示」，比如一个 *Config 指针；而不是文件本身。
如何用 atomic.StorePointer 实现配置热更新
当多个 goroutine 并发读配置，同时允许后台 goroutine 替换整个配置时，必须避免读到新旧混杂的字段（例如：读到新 Timeout 但旧 Host）。这时应让配置结构体不可变，并用 atomic.StorePointer 原子切换指针：
- 每次加载新配置，都构造一个全新
*Config实例（不能复用旧对象、不能改字段） - 写入前：用
unsafe.Pointer转换，再调atomic.StorePointer(&configPtr, unsafe.Pointer(newCfg)) - 读取时：用
cfg := (*Config)(atomic.LoadPointer(&configPtr))获取当前快照 - 禁止在
RWMutex临界区内对配置字段赋值——那会破坏不可变性假设
注意：atomic.StorePointer 第一个参数必须是 *unsafe.Pointer 类型，不能传 **Config；中间变量转换是必须步骤，硬写类型断言会触发未定义行为。
如何实现真正的原子文件写入（带权限控制）
目标是：写完才可见、崩溃不残留、权限符合预期。关键不是 atomic，而是利用 os.Rename 的原子性 + 显式 os.Chmod：
- 临时文件必须和目标文件同分区（否则
os.Rename会失败并退化为拷贝） - 用
os.CreateTemp(filepath.Dir(dst), filepath.Base(dst)+".tmp.*")创建临时文件（不依赖系统/tmp） - 写入完毕后，先
os.Rename(tmpPath, dst)—— 这步是原子的 - 再立即
os.Chmod(dst, perm)设置目标权限（0644或0600等） - 不要试图给
os.CreateTemp传宽松权限——它强制0600是安全设计，绕过它等于引入信息泄露风险
如果写入中途崩溃，临时文件留在磁盘但不会被业务逻辑读到；如果 Rename 后 Chmod 崩溃，文件已存在且内容完整，只是权限不对——这比内容损坏更容易人工干预修复。
并发读文件时要不要加锁？
绝大多数情况下：不用。因为 os.Open 返回的是独立的 *os.File，每个 goroutine 拥有自己的文件描述符和读偏移。多个 goroutine 并发读同一文件，只要不共享 bufio.Scanner 或 io.Reader 实例，就不会冲突。
但以下情况必须小心：
- 多个 goroutine 共享同一个
*os.File并调Read—— 读偏移会互相覆盖，结果不可预测 - 用
os.Mmap映射文件后，多个 goroutine 直接读内存区域 —— 需要自己保证读边界和缓存一致性 - 边读边删/重命名目标文件（如日志轮转）—— 此时文件描述符仍有效，但路径已失效，需提前
stat或监听 inotify
真正容易被忽略的点是：你以为在“并发读文件”，其实底层共用了缓冲区或状态机（比如单例 json.Decoder），这时候问题不在文件，而在那个被共享的对象。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
