Go os.File.Chmod 修改权限为什么在不同系统表现不同：模式位与平台限制

同一段 Go 代码在 Linux 上把文件改成 0644，换到 Windows 后却不像预期那样拥有三组读写权限，这不是 os.File.Chmod 失效，而是它遵循了目标操作系统自己的文件权限模型。Unix 会解释一组权限位和少量特殊模式位；Windows 当前主要使用 0o200 来切换只读属性。

把 Chmod 当成“按平台表达意图”的接口：Unix 上传入完整模式位，Windows 只用非零/零的可写意图，不要把 0644 当成所有系统都能还原的权限快照。

最小写法：先打开文件，再调用 os.File.Chmod

如果目标是让一个已经打开的文件在 Unix 上变成所有者可读写、其他用户只读，可以直接传入 0o644。八进制写法比十进制更接近权限位的阅读习惯，但它只在目标平台支持这些位时才有完整意义。

package main

import (
    "fmt"
    "os"
)

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

    if err := f.Chmod(0o644); err != nil {
        panic(err)
    }

    info, err := f.Stat()
    if err != nil {
        panic(err)
    }
    fmt.Printf("mode=%s\n", info.Mode().Perm())
}

这段代码的调用链是 os.OpenFile 打开 report.txt，再由 os.File.Chmod 接收 FileMode，最后通过 f.Stat 读取结果。这里的验证不是装饰：如果只看 Chmod 返回 nil，就无法知道目标系统是否按你想的方式解释了模式。

模式位在 Unix 与 Windows 上不是同一张表

官方 os.Chmod 文档明确说明，模式位的子集取决于操作系统。Unix 解释 ModePerm 的九个权限位，也会使用 ModeSetuid、ModeSetgid 和 ModeSticky；Windows 当前只使用 0o200，用它控制文件是否带有只读属性。

因此，在 Windows 上传入 0o644 的结果不能被解释成完整的 Unix 权限；它只是因为含有 0o200 而表达了“允许写入”。反过来，传入 0o400 可以表达只读意图，官方还建议为了兼容旧版本使用非零模式。

跨平台代码应先定义意图，再选择模式

如果业务需求只是“生成的报告之后不能被应用改写”，代码可以把它描述为只读意图，再根据编译目标或运行结果选择实现。不要在业务层到处散落 0644、0444，然后假设这些数字在每个平台都对应同一件事。

func makeReadOnly(f *os.File) error {
    // 0o400 在 Unix 表达读权限；在 Windows 表达不含 0o200 的只读意图。
    return f.Chmod(0o400)
}

func makeWritable(f *os.File) error {
    // 0o600 含有 0o200，Windows 会清除只读属性。
    return f.Chmod(0o600)
}

这两个函数的名字说的是业务意图，参数仍然保留在一个很小的适配边界里。若还需要验证，调用 f.Stat 后在 Unix 检查 ModePerm，在 Windows 检查后续写入是否成功；不要用一套字符串化权限作为跨平台断言。

三个容易误判的边界

把 Chmod 当成创建权限参数

os.OpenFile 的创建模式和 Chmod 是两个时机。文件已经存在时，OpenFile 的创建模式不会重新替换现有权限；需要变更现状，就明确调用 f.Chmod 并检查错误。

忽略符号链接的目标语义

对路径调用 os.Chmod 时，如果目标是符号链接，文档规定修改的是链接指向的目标。清理或部署脚本若不希望跟随链接，应在调用前单独做路径检查，不能从函数名推断出“只改链接本身”。

只看返回值，不看最终状态

Chmod 返回 nil 只能说明调用没有报告错误。权限显示、只读属性和后续写入能力仍受平台、挂载方式和用户身份影响；至少在关键流程中用 Stat 或一次受控写入做验收。

相关问题

为什么 Windows 上的 0644 不等于 Unix 的 0644？

因为 Windows 当前只使用模式中的 0o200 来控制只读属性，其余位没有 Unix 那样的读写分组含义。

os.Chmod 和 os.File.Chmod 怎么选？

已有文件句柄时用 os.File.Chmod 可以沿用打开对象；只有路径时用 os.Chmod。两者都应检查返回的 error。

Chmod 返回 nil 就一定能写文件吗？

不一定。用户身份、目录权限、挂载选项和平台属性都可能影响最终写入；关键路径要结合 Stat 或受控写入验证。

小结

os.File.Chmod 的核心不是把一个数字“同步到所有系统”，而是把 FileMode 交给当前平台解释。Unix 关心权限位和少量特殊位，Windows 主要关心 0o200 的可写意图。跨平台程序把模式常量集中管理、用业务语义命名，并在关键操作后验证实际状态，才能避免权限看似成功、行为却不一致。