必须在创建文件时就指定权限，不能靠os.chmod补救：os.writefile("token.txt", data, 0600)一步设私有权限，os.openfile("log.txt", os.o_create|os.o_append, 0644)设日志权限，注意0644是八进制且仅os.o_create时生效。
必须在创建文件时就指定权限，不能靠 os.Chmod 补救。 因为 os.Chmod 在 Windows 上基本无效、跨平台行为不一致，且存在竞态窗口和权限校验缺失风险。
os.WriteFile 和 os.OpenFile 创建时直接设权限
最安全的做法是在写入瞬间就设定权限，而不是事后调用 os.Chmod。比如密钥文件必须私有：os.WriteFile("token.txt", data, 0600)：一步到位，所有者可读写，组和其他人无任何权限。os.OpenFile("log.txt", os.O_CREATE|os.O_APPEND, 0644)：日志文件常用，所有者可读写，组和其他人只读。
注意：0644 是八进制，不是十进制 644；写成 644（没前导 0）会被 Go 当作八进制 1204 解析，结果完全不可控。实际生效权限还受系统 umask 影响（如 umask=0022 时，0666 会变成 0644），生产环境建议显式指定所需权限，不依赖默认值。
os.OpenFile 的 flag 组合决定写入行为和权限是否生效
权限参数（第三个参数）只有在 os.O_CREATE 被设置时才起作用。如果只是打开已有文件（比如 os.O_WRONLY 不带 os.O_CREATE），perm 参数会被忽略。
-
os.O_CREATE | os.O_WRONLY | os.O_TRUNC：覆盖写入，权限由perm决定 -
os.O_CREATE | os.O_WRONLY | os.O_APPEND：追加写入，权限由perm决定 -
os.O_CREATE | os.O_WRONLY（缺O_TRUNC或O_APPEND）：危险！会从头开始写但不截断原文件 → 写多少字节就覆盖多少字节，后面内容残留
若父目录不可写，哪怕 perm 设对了，也会在 OpenFile 阶段就报 permission denied。建议写入前先用 os.Stat 检查父目录是否存在且可写（os.IsPermission(err) 判断权限问题）。
os.Chmod 修改已有文件权限前必须预检
os.Chmod 不检查文件是否存在、是否为普通文件、当前用户是否是 owner，出错只返回泛化错误，容易误判。调用前务必先 os.Stat 预检：
-
info, err := os.Stat("config.yaml")，检查err != nil（文件不存在 / 权限不足） - 检查
info.Mode().IsRegular()（确保是普通文件，不是目录或设备） - 权限掩码要完整覆盖：想“仅关闭写位”，不能直接写
0444（会清掉执行位），而应做位运算：curr &^ 0222
Windows 上 os.Chmod 只识别只读/可写语义，0755 和 0644 效果一样，执行位 x 完全被忽略。跨平台权限逻辑必须收口处理——关键路径（如配置加载）应组合检查：存在 + 是普通文件 + 所有者匹配 + 权限 ≤ 0600。
原子写入时如何正确设置目标文件权限
避免用 os.CreateTemp + os.Chmod 两次操作：竞态窗口存在，且违反原子性原则。推荐方案是走“同目录临时文件 + os.Rename”路径：
- 临时文件用
0600创建（安全） -
os.Rename后目标文件继承父目录默认权限（由umask决定） - 再用
os.Chmod一次性修正——但这步仅在 Unix-like 系统有意义
关键点：os.Rename 是原子的，但权限修正不是；所以更稳妥的是让目标文件所在目录的 umask 符合预期（如启动前 syscall.Umask(0022)）。真正难处理的不是怎么设权限，而是怎么确保权限在写入完成那一刻就已确定且不可绕过——这要求你把权限决策嵌入到写入流程的第一步，而不是补丁式地加在最后。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
