os.OpenFile的mode参数需与umask按位运算得出实际权限，故传0600不保证文件最终为-rw-------；可靠做法是先OpenFile创建文件，再立即用f.Chmod(0600)修正权限，因其绕过umask且无竞态。
os.OpenFile 的 mode 参数不等于最终文件权限
直接传 0600 给 os.openfile 的第三个参数，不代表文件最终就是 -rw-------。linux 内核会先用你传的 mode 与当前进程的 umask 做位运算：实际权限 = mode & ^umask。比如进程 umask 是 0022，你传 0644，结果还是 0644；但你传 0600，结果是 0600 & ^0022 = 0600 & 0755 = 0600——看似没变，可一旦 umask 变成 0002，0600 & ^0002 = 0600 & 0775 = 0600 还是不变；但若你本意是 0660 却忘了考虑 umask，就可能得到 0640。
为什么 os.Chmod("path", perm) 不够可靠
调用 os.Chmod 改权限要两次系统调用（路径解析 + 权限设置），且存在竞态窗口：文件可能在 OpenFile 和 Chmod 之间被重命名、替换或删除。更关键的是，它无法绕过 umask 对创建阶段的影响——因为 umask 只作用于创建时的 mode，后续 Chmod 是独立操作，但时机晚了一步。
-
f, err := os.OpenFile("x", os.O_CREATE|os.O_WRONLY, 0600)创建时受umask影响 -
os.Chmod("x", 0600)是事后补救，不能保证原子性 - 正确做法是：先创建，再立刻对已打开的文件描述符调用
f.Chmod(0600)
f.Chmod 是绕过 umask 影响的最简方案
f.Chmod 直接作用于打开的文件描述符，不走路径查找，无竞态，且完全无视 umask——因为 umask 只在 open(2) 系统调用创建文件时起作用，之后的 fchmod(2) 调用不经过该逻辑。
- 必须确保
f是通过O_CREATE创建出来的，否则f.Chmod可能失败（如文件已存在且只读） - 顺序不能错：先
os.OpenFile(..., O_CREATE, ...)，拿到*os.File后立刻f.Chmod(perm) - 示例：
f, err := os.OpenFile("secret.txt", os.O_CREATE|os.O_WRONLY, 0666) if err != nil { log.Fatal(err) } if err := f.Chmod(0600); err != nil { log.Fatal(err) }
umask 是进程级的，Go 程序启动时就固定了
Go 程序继承启动它的 shell 的 umask，运行中无法全局修改（syscall.Umask 在多数现代 Go 版本中已被弃用或不可靠）。你不能指望在 main 函数开头调个 umask(0000) 就让所有后续 OpenFile 都生效——它只影响当前 goroutine 所在的系统线程，且行为未定义。真正可控的只有：显式传 mode，或用 f.Chmod 修正。
- 别在 Go 里试图改
umask，它不是 Go 的抽象层能安全封装的东西 - 如果你需要统一控制，默认在启动脚本里设好
umask 0077，再跑 Go 程序 - 但即便如此，仍推荐用
f.Chmod显式加固，因为依赖环境变量太脆弱
最易被忽略的一点：很多人以为只要 os.OpenFile 传了 0600 就万事大吉，却没意识到 umask 可能在别的 goroutine 或子进程中被意外修改（比如 exec.Command 启动的子进程继承了不同 umask），而 f.Chmod 是唯一能 100% 锁死权限的操作。
