Go 创建文件权限与 umask 不一致的排查

Go 创建文件时写了 0644，结果却看到 0600、0640 或权限没有变化，最常见的原因不是八进制写错，而是三个条件被混在了一起：传给 OpenFile 的模式、进程的 umask，以及目标文件是否已经存在。排查时先确认文件是新建还是复用，再按“请求模式 → umask → 实际模式”核对，通常很快就能定位。

官方文档：https://pkg.go.dev/os

新建文件时权限到底由谁决定

os.OpenFile(name, flag, perm) 的第三个参数是“希望新建时采用的模式”，不是每次打开文件都强制写入的模式。只有目标不存在且标志包含 os.O_CREATE 时，它才进入创建逻辑；目标已经存在时，重点变成打开方式和文件原来的权限。

例如下面的代码表达的是“新文件希望从 0640 开始”，并不承诺最终一定是 0640。代码里的注释只说明关键参数和关闭动作，实际权限还要结合运行进程的 umask 判断。

package main

import "os"

func createReport(path string) error {
	// O_CREATE 只在文件不存在时触发创建；0640 是创建请求模式。
	f, err := os.OpenFile(path, os.O_WRONLY|os.O_CREATE|os.O_TRUNC, 0o640)
	if err != nil {
		return err
	}
	// 关闭文件，避免描述符泄漏并把关闭错误交给调用方。
	return f.Close()
}

先查 umask，再怀疑 Go 的八进制写法

在 Unix 系统上，umask 是进程创建文件时使用的权限屏蔽值。假设 perm=0640、umask=0027，结果会是 0640 &^ 0027 = 0640；如果请求是 0666，同一个 umask 则会得到 0640。因此，看到组权限或其他权限位少了，先记录运行该 Go 进程的 shell、服务管理器或容器环境里的 umask。

这里不要用“把 perm 改大”作为万能修复。umask 可能来自启动脚本、systemd 服务配置、容器入口或父进程环境；同一份 Go 二进制在不同启动方式下得到不同结果是正常现象。还要注意：umask 影响的是创建动作，不会自动重写已经存在的文件。

# 查看当前 shell 的屏蔽值，先确认运行环境而不是猜测。
umask

# 用符号形式查看，便于和 rwxrwxrwx 权限位互相核对。
umask -S

如果程序必须在创建后保证一个明确的 Unix 权限，可以在成功创建后调用 Chmod，但这代表一次额外的权限调整。更稳妥的做法是先明确“默认权限由部署环境控制”还是“应用必须强制收敛到某个模式”，不要两边同时承担同一职责。

用 Stat 读出真正的权限结果

排障不要只看代码常量，也不要只看文件管理器的显示。os.Stat 返回 FileInfo，从 FileInfo.Mode() 得到 FileMode，再用 Perm() 单独取出九个普通权限位。这样可以把权限位和目录、符号链接等类型信息分开。

package main

import (
	"fmt"
	"io/fs"
	"os"
)

func inspect(path string) error {
	// Stat 读取目标元数据；错误先返回，避免把零值当成真实权限。
	info, err := os.Stat(path)
	if err != nil {
		return err
	}
	mode := info.Mode()
	// Perm 只保留 rwxrwxrwx，类型位和特殊位单独判断。
	fmt.Printf("perm=%#o regular=%t symlink=%t\n", mode.Perm(), mode.IsRegular(), mode&fs.ModeSymlink != 0)
	return nil
}

如果目标已经存在，测试 OpenFile 时应先把它移走或换一个新路径，否则你看到的权限可能是旧文件留下的。若程序需要“存在就覆盖内容，但不改变权限”，O_TRUNC 的行为正适合这个语义；若需要“存在也必须改成固定权限”，就把 Chmod 写成显式步骤并处理它的错误。

按现象选择修复方案

生产代码里，应用通常只负责提出合理的最小权限，部署层负责统一 umask；需要私密文件时再把“创建后 Chmod”作为明确的安全策略。还要留意竞态：创建、写入和权限调整之间存在窗口，敏感文件应结合专用目录、正确的创建标志和最小暴露时间设计，不能把一次 Chmod 当成全部安全边界。

相关问题

为什么 os.Create 创建出来不是 0666？

os.Create 的创建模式是 0666，但 Unix 的 umask 会屏蔽部分权限位，所以最终结果通常小于 0666；如果文件已存在，它会截断内容但不会用 0666 重置原权限。

Windows 上也能按 umask 解释吗？

不能直接照搬 Unix 公式。Go 文档说明 Windows 主要把 Chmod 的 owner-writable 位映射到只读属性，其他权限位当前没有同样语义；跨平台代码应把 Unix 权限判断限定在对应平台。