Go os.File.Chmod 在 Unix 与 Windows 上的差异：权限位写入何时不会按预期生效

把 Go 程序从 Linux 打包到 Windows 后，最容易出现的一类误判是：代码调用了 os.File.Chmod，日志也没有报错，但目标文件的权限表现和预期完全不同。原因通常不在调用时机，而在于同一个 FileMode 位在不同操作系统上并不代表同一件事。

Unix 会按权限位解释 Chmod；Windows 目前只把 0o200 当作“所有者可写”开关，用它控制文件的只读属性。跨平台代码不能把 0644 的语义直接照搬到 Windows。

同一个 Chmod 调用，平台解释并不相同

os.File.Chmod(mode) 的签名很简单，但 mode 的有效位由操作系统决定。Unix-like 系统使用权限位以及 setuid、setgid、sticky 等位，这组语义可以概括为 Unix permission bits；Windows 只使用 0o200 这一位，其他位目前没有实际作用，实际对应的是 Windows read-only attribute。

因此，下面这个调用在 Linux 上接近“设置为所有者可读写、其他人只读”，在 Windows 上却不能表达同样的三组用户权限：

if err := file.Chmod(0o644); err != nil {
    return fmt.Errorf("chmod report.txt: %w", err)
}

在 Windows 上，0o644 包含 0o200，所以它会把只读属性清掉，让文件保持可写；0o444 不包含 0o200，会把文件置为只读。这里的八进制数字仍然可以传入，但不能再按 Unix 的用户组权限表解释。

为什么 Windows 推荐用 0o400 和 0o600

Go 的 os 包文档给出了兼容性建议：在 Windows 上应传入非零 mode；需要只读时使用 0o400，需要可读写时使用 0o600。关键不是这两个数字在 Windows 上拥有 Unix 的完整权限含义，而是它们分别稳定地表达了“是否含有 0o200”。

func setWritable(file *os.File, writable bool) error {
    mode := os.FileMode(0o400)
    if writable {
        mode = 0o600
    }
    return file.Chmod(mode)
}

如果程序要同时支持 Unix 和 Windows，建议把“业务上的可写状态”先建模成布尔值，再在平台适配层选择 mode，而不是在业务代码里到处写 0644、0600。这样读代码的人能看出你要改变的是可写状态，不会误以为 Windows 也存在完全相同的 owner/group/other 权限矩阵。

用一个小程序验证两套结果

验证时不要只看 Chmod 返回值。它只说明系统调用是否成功，不能说明另一个平台是否按你心里的语义解释了 mode。下面的示例创建文件、设置模式，再读取 FileInfo.Mode().Perm()：

package main

import (
    "fmt"
    "os"
)

func main() {
    file, err := os.OpenFile("report.txt", os.O_CREATE|os.O_RDWR|os.O_TRUNC, 0o600)
    if err != nil {
        panic(err)
    }
    defer file.Close()

    if err := file.Chmod(0o400); err != nil {
        panic(err)
    }
    info, err := file.Stat()
    if err != nil {
        panic(err)
    }
    fmt.Printf("perm=%#o mode=%s\n", info.Mode().Perm(), info.Mode())
}

在 Unix 上，输出里的权限位可以用 ls -l report.txt 继续核对；在 Windows 上，更可靠的检查是关闭文件后重新以写入方式打开，观察是否得到权限错误，再调用 Chmod(0o600) 恢复可写状态，直到文件回到 writable file 状态。不要把 Windows 的 FileMode.Perm() 输出当作完整 NTFS ACL 报告。

符号链接和已有文件是另外两条边界

os.File.Chmod 面向的是打开的文件对象。按 os 包文档，若路径是符号链接，Chmod 修改的是链接目标，而不是链接本身。需要检查链接自身时，应先区分 os.Lstat 和 os.Stat 的语义，不要仅凭文件名判断。

另一个常见坑是把创建权限和后续修改权限混在一起。os.OpenFile 的创建 mode 会受 Unix umask 影响，而对已有文件调用 Chmod 是另一阶段的动作；Windows 则仍主要落到只读属性。排查问题时，先确认文件是否刚创建、是否经过符号链接，再判断平台。

提交前的跨平台检查清单

如果你的接口只是“把生成文件暂时设为不可写”，可以把平台差异封装在一个函数里；如果需求是完整的 Windows ACL 管理，就不要继续堆叠 FileMode 数字，应改用 Windows 原生权限模型或专门库，并把这部分能力从普通文件写入逻辑中隔离出来。

相关问题

Windows 上传入 0o644 会报错吗？

通常不会因为其他位存在而报错，但这些位目前没有 Unix 式权限效果；是否可写主要由 0o200 控制。

Chmod 能修改符号链接自身吗？

不能按这个接口的文档语义理解为修改链接自身；符号链接路径会作用到目标。需要区分链接自身和目标时，先用 os.Lstat 检查。

为什么只读 mode 不是 0o000？

在 Windows 兼容语义下，Go 文档建议使用非零 mode，并用 0o400 表示只读状态；不要用 Unix 的“清空所有权限”直觉推导 Windows 行为。

把权限意图写清楚，跨平台代码才不容易误导

Chmod 的调用成功并不等于权限语义跨平台一致。Unix 代码要按权限位验收，Windows 代码要围绕只读属性验收；当需求超过“可写/不可写”时，再把平台原生权限能力单独设计。这样既保留了 Go 标准库的可移植接口，也避免用一串八进制数字掩盖真实差异。