os.chmod 不支持递归修改目录权限，仅作用于单个文件或目录；必须手动遍历路径树并逐项调用，推荐使用 filepath.walkdir 安全实现，避免直接 exec.command("chmod", "-r") 带来的兼容性与安全问题。
用 os.Chmod 递归修改目录权限在 Go 中不可行
Go 标准库的 os.Chmod 只作用于单个文件或目录，不支持递归。直接对目录调用它，只会改该目录自身的权限，其下所有子项保持原样。这不是 bug，是设计使然——Go 倾向显式、可控的操作，避免隐式递归带来的误操作风险。
常见错误现象：
执行 os.Chmod("/path/to/dir", 0755) 后发现子文件仍是 0644，甚至子目录无法进入（因执行位缺失），但程序没报错，容易误以为成功。
- 必须手动遍历路径树，对每个项单独调用
os.Chmod - 注意：
os.Chmod对符号链接本身生效（而非目标），若需修改链接指向的目标，请用os.Lstat+os.Chmod组合判断 - 权限值（如
0755）是八进制字面量，不是十进制；写成755会变成十进制，结果完全错误
用 filepath.WalkDir 安全遍历并批量设权
filepath.WalkDir 是 Go 1.16+ 推荐的遍历方式，比旧版 filepath.Walk 更高效、更可控（可提前终止、跳过子树）。它天然适配递归 chmod 场景，且能区分文件、目录、链接等类型。
实操要点：
— 遍历时用 dirEntry.Type() 判断是否为目录，决定是否需要设置执行位（否则普通文件加 x 权限无意义，还可能被某些系统拒绝）
— 错误需逐项处理，不能因某个文件失败就中断整个流程（除非业务强要求）
err := filepath.WalkDir(path, func(p string, d fs.DirEntry, err error) error {
if err != nil {
return err // 跳过不可读目录等
}
mode := d.Type().Perm()
if d.IsDir() {
mode |= 0111 // 确保目录有执行位（用于 cd）
}
if err := os.Chmod(p, mode|0200); err != nil {
log.Printf("chmod failed on %s: %v", p, err)
}
return nil
})
调用系统 chmod 命令要警惕兼容性与安全边界
用 exec.Command("chmod", "-R", "755", path) 看似简洁，但实际生产环境应尽量避免：
- Linux/macOS 的
chmod -R行为不一致：macOS 默认不修改符号链接目标，Linux 可能受follow_symlinks策略影响 - 路径含空格、换行符或 shell 元字符时，直接拼接参数会引发命令注入或截断（即使使用
exec.Command，传参仍需确保path是干净字符串） - 无法细粒度控制——比如“只改目录不改文件”“跳过特定后缀”“遇到只读文件自动加
chattr -i”等需求，shell 命令难以优雅实现 - 跨平台失效：Windows 没有原生
chmod，exec.Command会直接失败（即使走icacls，语义和权限模型也完全不同）
权限掩码（umask）和继承行为不是 os.Chmod 能控制的
很多人期望“递归 chmod 后新创建的文件自动继承父目录权限”，但这和 os.Chmod 无关。Linux 下目录的 setgid 位（02000）可让新建文件继承组，而真正决定新建文件默认权限的是进程 umask（如 0022 会让 open() 默认生成 0644 文件），Go 中需用 syscall.Umask（非便携）或依赖启动环境。
所以：
— os.Chmod 只能修“已有项”的权限
— “未来文件权限”由创建它的代码（如 os.OpenFile 的 perm 参数）和系统 umask 共同决定
— 目录的 setgid 或 sticky 位需显式设置（如 02755），且仅对同组用户新建内容有效
递归修改这事，没有银弹。关键不在“怎么调用”，而在“想清楚每一层到底要什么权限”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
