创建文件时权限必须一步到位，避免竞态风险；os.openfile的perm参数仅在o_create时生效；windows上os.chmod几乎无效，跨平台权限控制应依赖应用层而非文件系统。
创建文件时权限就该定死，别等写完再改
Go 环境下最常踩的坑，是以为 os.Create 或 os.OpenFile 写完再调 os.Chmod 就万事大吉。其实这存在竞态窗口：文件落盘到调用 os.Chmod 之间，其他进程可能已读取敏感内容（比如密钥、配置）。真正安全的做法是一步到位。
-
os.WriteFile("token.txt", data, 0600)：所有者可读写，其余人完全无权访问 -
os.OpenFile("log.txt", os.O_CREATE|os.O_APPEND, 0644)：日志类文件常用，所有者可读写，组和其他人只读 -
os.Mkdir("cfg", 0700)：仅所有者可读、写、遍历，适合存放敏感配置的父目录
注意：0644 是八进制，不是十进制 644；写成 644 会被 Go 解释为八进制 1204，权限完全错乱。
os.OpenFile 的 perm 参数只在 O_CREATE 时生效
很多人传了 0600 却发现文件权限还是 0644，问题往往出在 flag 漏了 os.O_CREATE。只要文件已存在，perm 参数就被完全忽略——它不是“打开时的权限”，而是“新建时的初始权限”。
- ❌ 错误写法：
os.OpenFile("log.txt", os.O_WRONLY, 0644)—— 文件不存在时报no such file，且0644无效 - ✅ 正确写法：
os.OpenFile("log.txt", os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0644) - 覆盖写入用
os.O_TRUNC，追加用os.O_APPEND，二者不能同时用
权限值建议显式转为 os.FileMode 类型，比如 os.FileMode(0600)，语义更清晰。
跨平台权限行为差异极大，Windows 上 os.Chmod 几乎不生效
Linux/macOS 下 os.Chmod("x.sh", 0755) 能真正设执行位，但 Windows 上只会尝试设置 FILE_ATTRIBUTE_READONLY 标志，其余位（包括执行位、组/其他人权限）全部丢弃。这意味着：
-
os.Chmod("a.txt", 0755)和os.Chmod("a.txt", 0644)在 Windows 上效果一样 -
fi.Mode().Perm() & 0020 != 0在 Windows 上永远为 false，不能靠它判断“组是否可写” - 细粒度 ACL（如“仅 Administrator 可读”）必须用
golang.org/x/sys/windows调SetNamedSecurityInfo，标准库做不到
跨平台服务中，真正起效的权限控制必须落在应用层：路径白名单、JWT 校验、数据库查授权记录，而不是依赖文件系统权限。
修改已有文件权限前，必须先 os.Stat 预检
os.Chmod 不检查文件是否存在、是否为普通文件、当前用户是否有权操作，出错只返回泛化错误（如 operation not permitted），很难定位真实原因。安全做法是先预检：
- 调用
os.Stat确认文件存在且可访问 - 用
fi.Mode().IsRegular()排除目录、符号链接、设备文件等非普通文件 - 用
fi.Mode().Perm() & 0200 == 0判断所有者是否具备写权限（比字符串匹配更可靠） - 若目标是符号链接，
os.Chmod默认操作的是链接本身；需先os.Lstat判断，再决定是否解引用
实际生效权限还受系统 umask 影响（如 umask=0022 时，0666 变成 0644），生产环境必须显式指定所需值，不能依赖默认或事后补救。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
