Go 文件权限在不同机器不一致与 umask 有关吗

我第一次遇到“同一段 Go 代码在两台机器上创建出不同权限文件”时，直觉是怀疑 os.OpenFile 的第三个参数没有传对。后来把问题拆开才发现：在 Unix 系统上，perm 只是创建时申请的权限，最终结果还会受到当前进程的 umask 影响；而打开一个已经存在的文件，又是另一套行为。

所以答案是：有可能与 umask 有关，但不能只改 Go 代码里的 0644 就认定问题解决。先确认文件是否新建、进程运行在哪个平台，再看实际权限。

先把 0640 和最终权限分开看

os.OpenFile 在带有 os.O_CREATE 时，会把 perm 作为新文件的创建权限请求。Go 官方文档把它描述为“umask 之前”的权限。在 Linux 或 macOS 这类 Unix 系统上，可以把结果粗略理解成：

最终权限 = perm &^ umask

例如程序请求 0o640，当前进程的 umask 是 0o027，新文件通常会得到 0o640；如果请求是 0o666，同一个 umask 则会屏蔽组和其他用户的一部分写入位，常见结果是 0o640。这就是“代码没变、机器结果不同”的第一条线索。

这个判断只适用于创建权限的 Unix 语义。不要把 umask 当成 Go 的一个普通参数：它属于进程运行环境，通常由启动它的 shell、服务管理器或父进程带入。

新文件和旧文件不是同一个问题

排查时我最容易漏掉的是文件是否已经存在。只有文件不存在且带了 O_CREATE 时，perm 才参与创建。文件已经存在时，OpenFile 可以配合 O_TRUNC 清空内容，但不会因为你传入了新的 perm 就重置权限。

package main

import (
    "fmt"
    "os"
)

func createOrTruncate(path string) error {
    // 0o640 只约束新建文件；O_TRUNC 不会改写已有文件的权限位。
    file, err := os.OpenFile(path, os.O_WRONLY|os.O_CREATE|os.O_TRUNC, 0o640)
    if err != nil {
        return fmt.Errorf("打开文件失败: %w", err)
    }
    // 无论后续写入是否发生，都要及时关闭文件描述符。
    defer file.Close()
    return nil
}

因此，若部署目录里残留了旧文件，单纯修改 0o640 为 0o600 可能看不到变化。要明确改变已有文件，应该把权限调整作为独立动作，并记录这个动作是否被平台支持、是否有权限执行。

用一段小诊断记录环境差异

我通常先记录三个值：当前系统、请求的权限和 Stat 读到的实际权限。这个诊断不需要猜测 shell 配置，也不把“代码里的数字”误当成最终结果。

func reportMode(path string) error {
    // 先读取文件状态，Perm 只取 Unix 风格的九个权限位。
    info, err := os.Stat(path)
    if err != nil {
        return fmt.Errorf("读取文件状态失败: %w", err)
    }
    // GOOS 说明编译目标，实际运行环境仍应结合部署方式判断。
    fmt.Printf("GOOS=%s mode=%#o regular=%t\n", runtime.GOOS, info.Mode().Perm(), info.Mode().IsRegular())
    return nil
}

如果要把“创建前请求值”也写进日志，可以在调用 OpenFile 前保存一个常量，例如 requested := os.FileMode(0o640)。日志中的 requested 和 info.Mode().Perm() 不一致时，再去检查 umask、父目录默认 ACL 或程序是否实际打开了旧文件。

跨平台时不要把 Unix 权限位当成统一合同

在 Linux 和 macOS 上，权限位和 umask 是常见的文件创建语义；但 Windows 并不把 0o640、0o600 当成与 Unix 完全等价的访问控制模型。Go 的 os.FileMode 文档也明确提示，不同操作系统使用的模式位子集不同。

比较稳妥的做法是把需求写成两层：

• Unix 部署：明确创建权限，确认服务启动时的 umask，必要时对新建文件执行显式的 Chmod。
• Windows 部署：不要用 FileMode.Perm() 的数值去推导完整 ACL；需要访问控制时使用 Windows 对应的权限机制。

还要注意，Go 没有一个跨平台的、只读的标准库 GetUmask 函数。为了读取 umask 而临时调用 Unix 的 umask(0) 再恢复，会在并发进程中制造窗口；不要把这种做法当成普通诊断 API。更适合在服务启动配置或部署脚本中明确 umask，并把最终权限通过文件状态记录下来。

我会怎样收敛这个排查

先确认新旧文件，再把 requested、实际 Mode().Perm()、runtime.GOOS 和启动方式放在同一条诊断记录里。Unix 机器之间优先比较 umask；跨 Windows 时则停止比较权限数字，改看平台对应的访问控制。这样能把“Go 参数错了”“部署环境不同”和“旧文件没被重置”三个经常混在一起的问题分开。

官方资料：https://pkg.go.dev/os#OpenFile；https://pkg.go.dev/os#FileMode。

相关问题

为什么同样传 0666，创建出来经常不是 0666？ Unix 系统会在创建阶段应用当前进程的 umask，传入值是屏蔽前的请求值。

O_TRUNC 会把文件权限改成新的 perm 吗？ 不会。它负责截断已有内容，已有文件的权限不会因这个参数自动重置。

Go 能不能直接跨平台读取 umask？ 不能依赖一个跨平台标准库接口。Unix 的 umask 属于进程环境，Windows 也没有相同的权限模型。