atomic.storeint64对文件权限无效，因其仅保证内存变量读写原子性，无法干预chmod等系统调用；文件元数据修改依赖内核，需通过os.rename+os.lstat+os.chmod组合实现原子更新。
Go 里没有“原子指令”能直接更新文件元数据——sync/atomic 只管内存变量，对 chmod、chown、utime 这些系统调用完全无效。
为什么 atomic.StoreInt64 对文件权限没用
常见误解是把 os.Chmod 或 os.Chown 的结果用 atomic 包一层就“线程安全”了。其实：atomic 操作的对象必须是 Go 进程内定义的变量（比如 var mode int64），它无法干预系统调用本身是否成功、是否被其他进程覆盖。
例如你调用 os.Chmod("config.json", 0644)，这个操作本身不是原子的：可能刚改完权限，另一个进程又调回 0600；atomic 完全拦不住。
- 文件元数据（mode、uid、gid、mtime）由内核维护，修改靠
chmod(2)、chown(2)等系统调用 -
sync/atomic只保证对某个int64或指针的读写不被编译器重排、不被 CPU 乱序执行 - 如果你只是想缓存“上次设置的权限值”，可以用
atomic；但缓存 ≠ 实际生效
真正要保障元数据一致性，得靠 os.Rename + 元数据复制
所谓“原子更新元数据”，实际是指：在替换文件内容时，把旧文件的元数据（权限、属主、是否为 symlink）一并迁移到新文件上，且整个过程对外不可见中间态。这只能靠组合操作实现，不是单个指令能搞定的。
关键步骤必须包含：
- 用
os.Lstat读取原文件完整元数据，判断是否为符号链接（fi.Mode() & os.ModeSymlink != 0） - 写完临时文件后，立即调用
os.Chmod(tmpFile, fi.Mode())—— 注意 Windows 需过滤掉os.ModeSetuid等无效位 - 若为 symlink，先
os.Readlink获取目标，再os.Symlink创建新链接 - 最后用
os.Rename替换原路径，该操作在同文件系统下是元数据级原子的
并发写同一文件时，元数据竞态的真实来源
问题通常不出在“谁先改权限”，而出在“谁最后 rename”。多个 goroutine 同时走原子写流程，如果都用相同临时文件名（如硬编码 "config.json.tmp"），后启动的会覆盖前一个正在写的内容，导致最终 os.Rename 的是错误的文件 —— 权限可能被覆盖、symlink 可能被误删、甚至变成空文件。
正确做法：
- 临时文件必须用
os.CreateTemp(filepath.Dir(dst), "update-*.tmp")生成唯一路径 - 不要复用
os.WriteFile—— 它不暴露文件句柄，无法调f.Sync()，也无法设权限 - 写完临时文件后，必须
f.Sync()再f.Close()，否则os.Rename后可能读到未刷盘的旧权限或脏数据
Windows 下元数据丢失比 Linux 更隐蔽
Linux 上 os.Chmod 失败会立刻报错；Windows 却可能静默忽略某些位（比如 setuid），或因句柄占用导致 os.Rename 失败后没 fallback，最终留下权限错乱的临时文件。
必须显式处理：
- 捕获
os.Rename返回的syscall.ERROR_ACCESS_DENIED，fallback 到syscall.MoveFileEx带MOVEFILE_REPLACE_EXISTING | MOVEFILE_WRITE_THROUGH -
os.Chown在非管理员 Windows 或普通用户 Linux 下大概率失败，应忽略错误而非 panic - 测试时用
os.Stat读新文件验证 mode 是否真被应用，不能只信返回 nil error
最常被跳过的不是代码，而是语义：你到底想让“权限变更”对谁原子——是单次写入过程？还是跨进程可见性？前者靠 os.Rename + 元数据复制；后者必须引入外部协调（如文件锁、分布式共识），atomic 连边都碰不到。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
