Go 创建文件权限为什么和传入 mode 不完全相同

Go 创建文件时传入的 mode 是创建权限的请求值。在常见 Unix 环境中，没有父目录默认 ACL 等额外规则介入时，新文件权限可按 perm &^ umask 理解：例如请求 0666、umask 为 0022，得到 0644。如果文件已经存在，OpenFile 的 perm 不会重新设置它的权限。

官方地址：https://pkg.go.dev/os

判断本次是否真正创建文件

OpenFile 只有在目标不存在且包含 O_CREATE 时才使用 perm 创建文件。已有文件即使搭配 O_CREATE 打开，也不会重新套用 perm。WriteFile 对已有文件截断并写入，但不改变权限；Create 对新文件使用 0666（应用 umask 前）。第一次测试留下的文件，会让后续修改 mode 看起来不生效。

若任务要求只创建新文件，可使用 O_CREATE 与 O_EXCL，让已有目标返回错误。示例使用临时目录，不删除业务文件来试权限。

解释八进制与 umask 按位过滤

0o666 与传统的 0666 都是八进制，十进制 666 不是相同位模式。每组读、写、执行位分别是 4、2、1。0666 表示所有者、组、其他用户都请求读写，没有请求执行位。

umask 是按位屏蔽，不是数值减法，也不会补上执行位。普通 Unix 规则下，0666 与 0022 对应 0644，0666 与 0077 对应 0600，0600 与 0022 仍是 0600。这些是条件示例，不是本机运行输出。

Linux 父目录具有默认 ACL 时，创建规则还涉及 ACL 继承，不能只靠 umask 公式解释。进程通常继承启动环境的 umask，所以 shell 与服务进程可能不同。多协程服务不宜为了单次写文件临时来回修改进程级掩码，应明确启动配置与文件权限策略。

用完整 Go 示例观察权限

下面比较新建、重新打开与显式 Chmod。程序打印所在环境的实际权限，文中不预设所有机器都得到相同数值。

package main

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

func run() error {
    // 独立目录避免碰到已有业务文件。
    dir, err := os.MkdirTemp("", "perm-demo-")
    if err != nil { return err }
    defer os.RemoveAll(dir)
    name := filepath.Join(dir, "sample.txt")
    f, err := os.OpenFile(name, os.O_CREATE|os.O_EXCL|os.O_WRONLY, 0o666)
    if err != nil { return err }
    defer f.Close()
    info, err := f.Stat()
    if err != nil { return err }
    fmt.Printf("new: %04o\n", info.Mode().Perm())

    // 打开已有文件不重新设置权限。
    again, err := os.OpenFile(name, os.O_WRONLY, 0o600)
    if err != nil { return err }
    if err := again.Close(); err != nil { return err }
    info, err = f.Stat()
    if err != nil { return err }
    fmt.Printf("reopen: %04o\n", info.Mode().Perm())

    // 显式改权限要处理错误与平台差异。
    if err := f.Chmod(0o600); err != nil { return err }
    info, err = f.Stat()
    if err != nil { return err }
    fmt.Printf("chmod: %04o\n", info.Mode().Perm())
    return nil
}

func main() {
    if err := run(); err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }
}

在普通 Unix 规则、umask 为 0022 的条件下，前两处通常都是 0644，Chmod 成功后为 0600。如果第一处不同，先确认进程掩码和父目录规则；如果 Chmod 报错，保留错误信息分析权限与文件系统支持情况。

使用 Mode().Perm() 取得九个普通权限位，再以八进制打印；直接比较整个 FileMode 会把文件类型和特殊标志混入判断。

按需求使用文件句柄 Chmod

修改已打开文件权限时可调用 f.Chmod 并处理错误。Unix 上显式修改权限不再经过创建时的 umask 过滤。通过已打开句柄操作也避免再次通过同一路径查找对象，但仍受进程权限与文件系统能力约束。

如果文件从创建开始就只能由所有者读写，应直接请求 0600。不要先用宽松权限写入敏感内容，随后才收紧权限。如果业务需要组读取，应明确创建、文件身份与失败处理，再显式设置所需权限。

处理 Windows 与实际访问权限差异

Go 官方说明 Windows 的 Chmod 主要使用所有者可写位 0200 控制只读属性，其他权限位目前不用于实现 Unix 式用户与组权限。将 0644 改为 0600，不等同于配置 Windows 用户级 ACL。需要控制具体 Windows 账户访问时，应使用平台访问控制机制。

Unix 普通权限位符合预期，也不保证某个身份一定能访问。父目录搜索权限、ACL 和运行身份等会影响实际操作。“保存了什么权限位”和“某个进程能否访问”是两个问题。

传 0777 为什么不一定得到 0777？

新建时可能受 umask 与文件系统规则影响；已有文件则不因 OpenFile 的 perm 改变。普通数据文件通常不需要执行位。

O_TRUNC 会重置权限吗？

它截断内容，不等同于重新创建文件或调用 Chmod。

需要把 umask 改成 0 吗？

通常没有必要。先确认是否新建、八进制是否写对，再选择创建权限或 Chmod。统一放宽进程掩码还会影响其他创建操作。

参考：Go OpenFile、Go Chmod、Linux umask 与默认 ACL。