Go os.File保持替换文件的权限模式的处理方法

用临时文件替换配置、密钥或缓存文件时，不能只把内容写进去再调用 os.Rename。临时文件通常按新的创建权限产生，旧文件原本的 0o640、0o600 等模式不会自动跟随。可靠做法是先读取旧文件的权限位，再把这个模式应用到同目录的临时文件，写完整内容后同步、关闭，最后替换目标路径。

先保存旧文件的 mode，再把临时文件放在同目录

os.Stat 返回 FileInfo，其中 Mode().Perm() 只取普通权限位。例如旧文件是 -rw-r-----，得到的就是 0o640。目标不存在时不要把不存在当成异常退出，可以显式采用一个默认值；配置文件常见的是 0o600 或 0o640，是否可读应由业务决定。

临时文件应和目标文件位于同一目录。这样不仅便于 Rename，也避免临时目录和目标目录属于不同文件系统时无法直接移动。下面的写法只讨论普通文件替换，不负责锁竞争和目录持久化策略。

按写入、同步、关闭、替换的顺序完成更新

关键不是“先创建还是先写入”，而是让临时文件在替换前已经拥有正确权限，并且写入错误不会覆盖旧文件。os.CreateTemp 便于得到唯一文件名，但它的初始权限通常偏保守，所以这里仍显式调用 Chmod。成功 Rename 后设置 renamed=true，清理函数只删除尚未替换的临时文件。

package main

import (
	"fmt"
	"os"
	"path/filepath"
)

// replaceFile 保留旧文件的普通权限位，并用同目录临时文件完成替换。
func replaceFile(target string, content []byte) (err error) {
	mode := os.FileMode(0o640) // 目标不存在时使用明确的业务默认值。
	if info, statErr := os.Stat(target); statErr == nil {
		mode = info.Mode().Perm() // 只保留权限位，不把目录或符号位带入创建权限。
	} else if !os.IsNotExist(statErr) {
		return fmt.Errorf("读取旧文件权限: %w", statErr) // 其他 Stat 错误不能静默忽略。
	}

	dir := filepath.Dir(target) // 同目录让 Rename 更容易满足同一文件系统要求。
	tmp, err := os.CreateTemp(dir, ".replace-*")
	if err != nil {
		return fmt.Errorf("创建临时文件: %w", err)
	}
	tmpName := tmp.Name()
	renamed := false
	defer func() {
		if !renamed {
			_ = os.Remove(tmpName) // Rename 未成功时才清理，避免误删新目标。
		}
	}()

	if err = tmp.Chmod(mode); err != nil {
		_ = tmp.Close() // Chmod 失败时优先返回原错误。
		return fmt.Errorf("设置临时文件权限: %w", err)
	}
	if _, err = tmp.Write(content); err != nil {
		_ = tmp.Close() // Write 失败时先关闭句柄，再把错误交给调用方。
		return fmt.Errorf("写入临时文件: %w", err)
	}
	if err = tmp.Sync(); err != nil {
		_ = tmp.Close() // Sync 失败表示持久化要求未满足，不应继续替换。
		return fmt.Errorf("同步临时文件: %w", err)
	}
	if err = tmp.Close(); err != nil {
		return fmt.Errorf("关闭临时文件: %w", err)
	}
	if err = os.Rename(tmpName, target); err != nil {
		return fmt.Errorf("替换目标文件: %w", err)
	}
	renamed = true
	return nil
}

func main() {
	if err := replaceFile("settings.json", []byte("{\"enabled\":true}\n")); err != nil {
		fmt.Println(err) // 示例只输出错误，生产代码应接入结构化日志。
	}
}

这段代码的权限保持发生在 tmp.Chmod(mode)，而不是 Rename 之后。若先替换再修改权限，读者和其他进程可能在短时间内看到不符合策略的模式；更重要的是，修改权限失败时新内容已经暴露。

权限保持不住时先区分 umask、平台和符号链接

在 Unix 上，OpenFile 或创建临时文件给出的权限还会受到进程 umask 影响，因此“创建时传了 0o640”不等于最终一定是 0o640。本方案在创建后显式 Chmod，更接近“替换后保持旧权限”的目标，但进程仍需要拥有修改权限的能力。

os.Rename 在 Unix 同目录普通文件上通常适合做原子名字替换；Go 官方文档同时提示，不同操作系统有不同限制，非 Unix 平台不应直接套用原子性假设。Windows 的 Chmod 主要控制只读属性，不能把它当成 Unix 的用户、组和其他人三组权限。另一个容易忽略的边界是符号链接：Stat 会跟随链接读取目标信息，而 Rename 替换的是链接路径本身。

如果业务还要求断电后目录项也稳定落盘，File.Sync 只覆盖文件内容的同步语义，目录同步和平台差异需要单独设计；这已经超出本文的权限保持范围。

常见问题

为什么不能只在 Rename 后调用 Chmod

可以做到，但替换后的短窗口会暴露临时文件的默认权限，而且 Chmod 失败时内容已经成为新文件。把权限先设在临时文件上，失败可以保留旧文件。

FileMode 要不要直接传给 Chmod

通常只传 Mode().Perm()。这样不会把目录、符号链接、设备文件等类型位一起当作普通权限；若确实要处理特殊位，应按 Unix 目标和权限模型单独设计。

临时文件能不能放到系统临时目录

如果最终要用 Rename 替换目标，优先放在目标同目录。跨文件系统移动可能失败，退化为复制再删除又会失去替换过程的清晰边界。