能，但需用八进制字面量（如0755）传参，不能写十进制755；它仅修改权限位，不改变所有权，且Windows忽略执行位、仅支持读写语义。
Go 中 os.Chmod 能否直接修改文件权限？
能，但要注意它只改权限位，不处理用户/组所有权。也就是说，os.Chmod 仅对应 Unix 的 chmod 命令行为，不等价于 chown 或 chgrp。
常见错误是以为传入 0755 就万事大吉——实际必须用八进制字面量写法 0755（前面带 0），写成 755 会被解释为十进制，结果变成 01143 八进制，权限完全错乱。
-
os.Chmod("file.txt", 0755)✅ 正确：八进制权限 -
os.Chmod("file.txt", 755)❌ 错误：十进制 755 → 八进制 1363 → 权限混乱 - Windows 上调用
os.Chmod会静默忽略执行位（x），仅保留读写位，这点常被忽略
如何在 Go 中同时设置权限和所有者（UID/GID）？
标准库不提供跨平台的 chown 支持，os.Chown 在 Windows 上返回 syscall.ENOSYS 错误，不能用。
Linux/macOS 下可用 os.Chown，但需注意：
立即学习“go语言免费学习笔记（深入）”；
- UID/GID 必须是数值，不是用户名或组名；查 uid 需自己调用
user.Lookup或user.LookupGroup - 非 root 进程无法将文件所有者设为他人，只能改自己拥有的文件的组（且目标组需在用户 supplementary groups 中）
- 推荐组合使用：
os.Chown+os.Chmod，顺序无关，但建议先 chown 再 chmod，避免因权限不足导致 chown 失败
示例片段：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
uid, err := user.Lookup("alice")
if err != nil { panic(err) }
gid, err := user.LookupGroup("dev")
if err != nil { panic(err) }
os.Chown("script.sh", uid.Uid, gid.Gid)
os.Chmod("script.sh", 0750)
为什么 os.ModePerm 不等于 0777？
os.ModePerm 是 Go 对“所有权限位”的抽象掩码，值为 0777（八进制），但它只影响权限位（rwxrwxrwx），不包含文件类型位（如目录 d、符号链接 l、套接字 s 等）。
容易踩的坑：
- 直接用
os.ModePerm调用os.Chmod是安全的，它等价于0777 - 但若从
os.FileInfo.Mode()获取模式，需先用& os.ModePerm屏蔽掉类型位，否则可能误把目录位（040000）当权限参与运算 - 比如：
fi.Mode() & os.ModePerm才是真正的权限部分；fi.Mode().Perm()是更简洁的等价写法
创建新文件时如何确保权限不被 umask 干扰？
Go 的 os.Create 和 os.OpenFile 默认使用 0666 权限，受进程 umask 影响。比如 umask 是 0022，最终文件权限就是 0644。
要绕过 umask，必须显式指定权限，并用 os.O_CREATE | os.O_WRONLY 等 flag 打开文件：
-
os.OpenFile("log.txt", os.O_CREATE|os.O_WRONLY, 0600)✅ 创建私有日志文件 -
os.Create("temp.txt")❌ 权限由 umask 决定，不可控 - 注意：即使指定
0777，umask 仍会生效；真正“强制”需要先syscall.Umask(0)（不推荐，影响全局）
生产环境建议始终显式传入所需权限，别依赖默认值或 umask。
权限位计算和平台差异比看起来复杂得多，尤其混合部署时 Linux 和 Windows 行为不一致，最稳妥的方式是：明确写八进制、屏蔽类型位、创建时固定权限、变更所有权前确认运行身份。
