Go中创建文件时应立即设置权限,推荐用os.WriteFile("token.txt", data, 0600)一步到位;权限值须用八进制(如0644),注意umask影响,修改前需os.Stat预检,跨平台权限逻辑需收口处理。

创建文件时就该定好权限,别等写完再改
Go 中最安全的做法是在 os.OpenFile 或 os.WriteFile 创建文件的瞬间就设好权限,而不是事后调用 os.Chmod 补救——因为中间存在时间窗口,敏感内容可能被其他进程读到。
-
os.WriteFile("token.txt", data, 0600):一步到位,写入即私有,推荐用于密钥、配置等敏感文件 -
os.OpenFile("log.txt", os.O_CREATE|os.O_APPEND, 0644):日志类文件常用,所有者可读写,组和其他人只读 - 注意:
0644是八进制,不是十进制644;写成644会被解释为八进制1204,结果完全不可控 - 实际生效权限还受系统
umask影响(如 umask=0022 时,0666会变成0644),生产环境建议显式指定所需权限,不依赖默认值
修改已有文件权限要用 os.Chmod,但得先确认文件存在且可访问
os.Chmod 不检查文件是否真实存在或当前用户是否有权修改它,出错时只返回 operation not permitted 或 no such file 这类泛化错误,容易误判。
- 务必在调用前用
os.Stat预检:info, err := os.Stat("config.yaml") if err != nil { log.Fatal("文件不存在或无访问权限:", err) } if !info.Mode().IsRegular() { log.Fatal("目标不是普通文件") } - 权限掩码要完整覆盖,比如想“仅关闭写位”,不能直接写
0444(会意外清掉执行位),而应按位操作:curr &^ 0222 - Windows 上
os.Chmod只识别只读/可写语义,0755和0644效果可能一样,执行位x完全被忽略
读取文件前检查权限,比报错后再处理更可靠
很多程序假设“能打开就能读”,但实际中文件可能被设为只读、甚至被其他用户 chown 掉,导致后续写操作失败。提前校验可快速失败、明确归因。
- 用
info.Mode().Perm()提取纯权限位,再做位运算判断:if info.Mode().Perm()&0200 == 0 { log.Println("警告:所有者无写权限,无法更新该配置") } - 避免用字符串匹配权限(如
info.Mode().String()返回-rw-r--r--),解析脆弱且跨平台不一致 - 对关键配置文件,建议组合检查:是否存在 + 是普通文件 + 所有者匹配 + 权限 ≤ 0600
跨平台权限逻辑必须收口,别让 Linux 习惯带到 Windows
Go 的权限 API 在 Windows 上是模拟层,0755、0644 等数值虽可传入,但底层只映射为“只读”或“可写”两个状态,组/其他人权限、执行位全部失效。
- 不要在 Windows 上依赖
x位判断脚本是否可执行;也不要指望0660能限制组访问 - 若需多平台一致行为,把权限意图写进文档或部署脚本里,例如:“该文件必须由当前用户独占读写”,然后在 Linux 用
chown+chmod,Windows 用attrib +R等等 - CI/CD 流程中,可在 Linux 环境下跑一次
ls -l校验,避免本地开发(macOS)和部署(Linux)权限不一致
0600 最终能否落地,取决于运行时的 OS、用户身份、umask、挂载选项,甚至 SELinux 策略。所以别只测函数返回 nil,要测最终 ls -l 看到的结果。










