os.Chmod返回nil不保证权限生效，因Windows忽略执行位、Docker/NFS等文件系统可能静默失败，需调用os.Stat比对实际权限；符号链接默认修改目标文件而非链接自身；权限字面量必须带前导0（如0644），否则按十进制解析导致错误。
os.Chmod 返回 nil 不代表权限已生效
调用 os.Chmod 成功返回 nil，只说明系统调用没出错，不代表你传的权限值真的写进了文件元数据。尤其在以下场景中，它可能静默失败：
- Windows NTFS 或 WSL2 下，
0755中的执行位（x）会被完全忽略，0644和0755实际效果可能一样——只保留读/写语义 - Docker 容器挂载 host 路径时，若用
mount -o uid=1001,gid=1001方式，os.Chmod可能不报错但也不生效 - APFS 加密卷、NFSv3 等文件系统对元数据更新有延迟或映射限制，
Stat()两次比对可能仍显示旧值
实操建议：必须在 os.Chmod 后立即 os.Stat 并提取权限位比对：
fi, err := os.Stat("config.yaml")
if err != nil {
log.Fatal(err)
}
actual := fi.Mode() & 0777
if actual != 0600 {
log.Printf("Chmod failed: expected 0600, got %o", actual)
}
os.Chmod 对符号链接的默认行为是改目标文件
这是最容易踩的坑：你 os.Chmod("link.txt", 0600)，结果改的是它指向的真实文件，而不是链接本身。如果你本意是限制谁可以修改这个链接（比如防止被 rm 或 ln -sf 替换），那就错了。
- 要改链接自身权限，得用
os.Lchmod（仅 Unix-like 系统支持，Windows 不可用） - 更兼容的做法是先
os.Lstat判断是否为符号链接：fi.Mode()&os.ModeSymlink != 0 - 如果是链接，且你想改目标文件权限，应显式
os.Stat+os.Chmod；如果想改链接本身，需降级到syscall层（如syscall.Lchmod），或放弃跨平台
权限值写成 644 而不是 0644 就会出大问题
Go 把没有前导 0 的数字当十进制解析。644 是十进制，等于八进制 1204，对应权限位是 r----x--T（含 setuid + sticky bit），完全不是你想要的 rw-r--r--。
立即学习“go语言免费学习笔记（深入）”；
- 所有权限字面量必须带前导
0：0600、0755、0644 - 别依赖
os.FileMode(644)—— 这里传进去的仍是十进制 644，等价于错误写法 - IDE 或 linter（如
staticcheck）可配规则检测无前导零的权限字面量，建议启用
批量递归设权限时，目录和文件必须分开处理
用 filepath.Walk 统一设 0600？那你会把所有目录也变成不可遍历（缺 x 位），导致后续 cd 或 ls 失败。
- 必须用
os.Lstat（避免跟随链接）+fi.Mode().IsDir()分流 - 目录推荐
0755（所有者全权，组和其他人可读+遍历），普通文件用0600或0644 - 跳过特殊文件：
fi.Mode()&os.ModeType != 0，过滤掉 socket、device、named pipe 等 - 错误不能吞：回调里每个
os.Chmod都要检查err，并显式return err中断遍历，否则失败项会被忽略
真正难的不是调用 os.Chmod，而是判断该不该调、在哪调、调完有没有效。尤其是跨平台和容器环境，权限不是“设了就完事”，而是一连串需要验证的元数据状态变更。
