Go的os.Chmod在Linux/macOS上完整生效，但在Windows上仅支持读写状态（如os.ModeReadOnly），执行位（x）被静默丢弃，因NTFS/FAT不支持Unix权限；其返回“operation not permitted”主因是用户非文件所有者、路径位于noexec挂载点、为符号链接或文件系统只读。
Go 的 os.Chmod 能设权限，但“能设”不等于“设对”——它不校验路径是否可写、不处理符号链接、不绕过 umask、也不跨平台一致生效。直接调用前，必须确认所有权、路径语义和目标系统行为。
为什么 os.Chmod("x.sh", 0755) 在 Linux 有效，在 Windows 却没执行位
Windows 文件系统（NTFS/FAT）根本不支持 Unix 风格的执行权限（x 位）。os.Chmod 在 Windows 上只响应 os.ModeReadOnly 对应的读写状态：传入 0755 或 0644，最终都只可能表现为“只读”或“可写”，x 位被静默丢弃。这不是 bug，是设计限制。
- Linux/macOS：权限位完整生效，
0755→ 所有者 rwx，组/其他 rx - Windows：
0600和0700效果相同（都是可写），0444强制只读 - 若需跨平台可执行逻辑，不要依赖文件权限，改用显式调用解释器（如
exec.Command("sh", "x.sh")）或封装为 Go 子命令
os.Chmod 返回 "operation not permitted" 的真实原因
这个错误几乎从不因为代码写错，而是运行时权限模型拒绝操作。常见触发点：
- 当前进程用户不是文件所有者，且非 root（Linux/macOS 强制要求）
- 文件位于 noexec/nosuid 挂载点（如 Docker volume、FAT32 分区、某些 macOS 加密卷）
- 路径是符号链接，而你本意是改目标文件权限（
os.Chmod默认 follow symlink；要改链接本身，得用os.Lchmod，仅 Unix 支持） - 文件系统只读（如
/proc、CD-ROM、某些容器临时文件系统）
排查建议：先 os.Stat 确认存在，再检查 fi.Sys().(*syscall.Stat_t).Uid 是否匹配 syscall.Getuid()；避免在未知挂载选项的路径上硬调用。
立即学习“go语言免费学习笔记（深入）”；
如何安全地设置权限，避开 umask 和竞态
os.Chmod 不受 umask 影响——它强制覆写权限位。但问题在于：先 os.WriteFile 再 os.Chmod 是两步操作，中间存在权限错误窗口（比如文件已写入但尚未 chmod，被其他进程读取）。
- 更安全的做法是在创建/写入时一步指定权限：
os.WriteFile("config.json", data, 0600) - 若必须分步（如追加写、原子重命名后 chmod），务必检查
os.WriteFile的error，失败则绝不调用os.Chmod - 对目录设权限时，注意执行位（
x）在目录中表示“可遍历”，缺它会导致openat类系统调用失败，不是“不能执行” - 避免
0777，尤其在多用户环境；临时文件优先用0600+ 显式os.Remove清理
读取当前权限并做条件判断的正确方式
别用 fi.Mode() & 0755 == 0755 这类位运算——fi.Mode() 是 os.FileMode 类型，高位含类型标识（如 os.ModeDir），直接与八进制字面量比会出错。
- 提取纯权限位：用
fi.Mode().Perm()，它只返回低 9 位 - 判断是否可执行：
fi.Mode().Perm()&0111 != 0（注意是八进制0111，不是十六进制） - 判断是否为目录：
fi.Mode().IsDir()，而非fi.Mode() & os.ModeDir != 0 - 符号链接判断：
os.Lstat获取链接自身元信息，os.Stat获取目标文件元信息——选错就拿错权限
最易被忽略的是：权限判断逻辑写在 os.Chmod 调用前，却忘了 os.Stat 可能因权限不足而失败——它本身也需要读取文件元数据的权限，不是只读文件也能 Stat 成功。
