os.Chmod无法单独修改组权限，必须传入完整八进制模式（如0644），通过os.Stat读取现有权限后用位运算调整（如curr|0020加组写），并注意Windows仅支持只读/可写两级模拟。
os.Chmod 不能按用户组单独设置权限
Go 没有提供类似 Linux chmod g+w 这种“只改组权限位”的原生函数。os.Chmod 必须传入完整权限模式（如 0644），它会覆盖全部三组（user/group/other）的 rwx 位，无法增量修改。
常见错误是想“只给组加写权限”，却直接传 0020——这会被解释为八进制 0020（即十进制 16），实际清掉所有位再设一个特殊标志，结果文件变成不可读不可写。
- 正确做法：先用
os.Stat读出现有权限，再用位运算调整 - 例如给组加写：
curr | 0020；去掉组写：curr &^ 0020 - 别漏掉执行位影响：若原权限含
x（如0755），只写0644会意外清除组和其他人的执行位
设置文件属主和属组要用 os.Chown，但 Windows 不支持
os.Chown 是唯一能改 UID/GID 的标准函数，但它在 Windows 上会 panic，且在 Linux/macOS 上受严格限制：
- 必须由 root 或当前文件 owner 调用，才能改 owner；改 group 需 owner 或 root
- macOS 要求 UID/GID 真实存在于系统数据库（
/etc/passwd），填个不存在的数字会静默失败 - Docker 容器内非 root 用户几乎必然失败，除非启用了 user namespace remapping
跨平台安全写法：
立即学习“go语言免费学习笔记（深入）”；
if runtime.GOOS != "windows" {
err := os.Chown("config.yaml", uid, gid)
if err != nil {
log.Printf("Chown skipped: %v", err)
}
}
文件创建时就该定死权限，别依赖 umask
像 os.Create 默认用 0666，但最终生效权限 = 0666 &^ umask。生产环境 umask 常为 0022 或 0002，结果不可控。
- 敏感文件（如 token、私钥）必须用
os.WriteFile("key.pem", data, 0600)一步到位 - 日志类文件推荐
os.OpenFile("app.log", os.O_CREATE|os.O_APPEND, 0644) - 切记：
0644是八进制字面量，写成644就是十进制 → 八进制1204，权限彻底错乱
Windows 上权限只是“可写 / 只读”两级模拟
Windows 不区分 user/group/other，也不认执行位。传给 os.Chmod 的 0755、0644 全部被降级为：0（只读）或非 0（可写）。其他位全丢，不报错也不警告。
这意味着：
- 跨平台程序不能靠权限位判断“是否可执行”，得用
os.IsNotExist或exec.LookPath - 检查组权限逻辑（如
info.Mode().Perm() & 0020 != 0）在 Windows 上永远为 false - 真正需要细粒度控制的场景，得收口到平台适配层，比如 Linux 走 chmod/chown，Windows 改 ACL（需调用 syscall）
