os.Chown在Windows上无效，Linux/macOS需root权限改属主；os.Chmod可用但需注意八进制字面量（如0644）、路径写权限及符号链接默认操作目标文件。
直接说结论：用 os.Chmod 改权限没问题，但 os.Chown 在 Windows 上基本无效，且在 Linux/macOS 上需要 root 权限才能改属主；多数场景下，你真正需要的只是 os.Chmod，而 os.Chown 应谨慎调用。
os.Chmod 的正确用法和常见错误
os.Chmod 用来修改文件或目录的 Unix 权限位（如 0644、0755），它不依赖用户权限，普通用户也能调用成功——只要对目标路径有写权限（即能修改其元数据）。
- 权限值必须是
os.FileMode类型，直接传整数会编译失败：错写成os.Chmod("file.txt", 644)→ 正确应为os.Chmod("file.txt", 0644)（注意前导0表示八进制） - 目录默认不递归，要批量改子项得自己遍历：
filepath.WalkDir配合os.Chmod - 注意符号链接行为：默认修改的是链接本身（不是目标文件），加
os.Lchown才能操作链接目标 —— 但os.Chmod没有对应 L 版本，它对符号链接总是操作目标文件
err := os.Chmod("config.yaml", 0600)
if err != nil {
log.Fatal(err) // 比如 "operation not permitted" 通常意味着父目录不可写
}
os.Chown 在不同系统上的表现差异
os.Chown 的行为高度依赖操作系统，且容易被误用。它接受 uid/gid 两个整数参数，但这些数字在各平台含义不同。
- Linux/macOS：需真实 uid/gid 数字（查
id -u或getent passwd username），普通用户只能将文件 chown 给自己或所属组，改属主必须 root - Windows：完全忽略 uid/gid 参数，调用返回 nil 但实际无任何效果（不会报错，也不会改所有权）
- 容器环境（如 Docker）：即使以 root 运行，若挂载卷来自宿主机，chown 可能因 mount 选项（如
uid=1001,gid=1001）被内核拦截
所以别写 os.Chown(path, 1001, 1001) 然后假设它“生效了”——先确认运行环境是否支持，再检查返回 err 是否为 nil。
替代方案：什么时候该用 exec.Command("chmod") 或 "chown"
当你要做的事超出 os.Chmod/os.Chown 能力范围时，调用 shell 命令反而更可靠。
- 需要递归修改（
-R）：标准库没提供，自己 walk + chmod 易出竞态，不如exec.Command("chmod", "-R", "755", path) - 按用户名/组名设置（非数字 ID）：Go 标准库不解析
username:groupname字符串，得自己查user.Lookup和user.LookupGroup，再转 uid/gid，中间还可能失败；直接跑chown user:group file更直白 - 某些 NFS 或 overlayfs 文件系统对 syscall.chown 敏感，但接受 shell 层命令
注意：用 exec.Command 要校验 PATH、处理空格路径（加 cmd.Args = []string{...}）、捕获 stderr。
权限掩码和 umask 的隐式影响
os.Chmod 是“覆盖式”设置，但新建文件的初始权限受进程 umask 影响；而 os.Chmod 本身不受 umask 干扰。这点常被混淆。
- 比如进程 umask 是 0022，你用
ioutil.WriteFile("x", data, 0666)，实际得到的是 0644 —— 但后续调用os.Chmod("x", 0666)就真变成 0666 - 安全敏感场景（如密钥文件）务必显式设为 0600，不能依赖 umask 或“默认安全”
- 注意
os.ModeSetuid、os.ModeSticky等特殊位：它们不是普通读写执行，需用按位或组合，例如01777表示带 sticky bit 的 world-writable 目录
最常被忽略的一点：修改权限后，如果文件正被其他进程 mmap 或以只读方式打开，新权限不会立刻影响那些已打开的 fd —— 权限检查发生在 open() 时，不是 read()/write() 时。
