调用 os.chmod 前必须确认文件存在且为普通文件、当前用户是所有者、父目录有执行权限；符号链接需区分操作目标或链接本身；跨平台权限值需按系统适配，windows 仅识别读写语义。
直接调用 os.Chmod 修改已有文件权限是可行的，但多数失败不是代码写错了，而是调用前没确认文件状态、所有权或路径语义——尤其在容器、macOS 或 Windows 下极易静默失效。
调用 os.Chmod 前必须做的三件事
它不校验任何前提条件，只管设 mode 位。跳过预检，等于把错误留给生产环境排查。
- 用
os.Stat确认文件存在且是普通文件：fi.Mode().IsRegular()，避免误改目录或设备节点 - 检查当前进程用户是否为文件所有者（
fi.Sys().(*syscall.Stat_t).Uid == uint32(os.Getuid())），Linux/macOS 下非 owner 无法Chmod - 确认父目录有执行权限（
x）：没有它，连os.Stat都可能失败，更别说Chmod
os.Chmod 在符号链接上的行为陷阱
默认操作的是链接本身，不是目标文件。你看到 ls -l 显示 lrwxr-xr-x，Chmod 改的正是这个 l 开头的链接文件权限，而非它指向的实体。
- 想改目标文件？先
os.Stat（自动跟随），再Chmod - 想改链接本身？用
os.Lstat判断后，再调os.Chmod—— 但注意os.Lchmod才真正改链接元数据，且仅 Unix-like 系统支持 - Windows 下符号链接权限基本无效，
Chmod只影响os.ModeReadOnly位
跨平台权限值怎么写才不会翻车
0644 在 Linux 是“所有者读写、组/他人只读”，在 Windows 就只是“可读写”；0755 的执行位（x）在 Windows 完全被忽略。别指望数值一致，得按平台收口。
- 八进制字面量必须带前导
0：0644✅，644❌（Go 当作十进制 644 = 八进制 1204，结果不可控） - Windows 有效权限只有两种语义：
0666（可读写）和0444（只读），其余位（如x、组/他人区分）会被丢弃 - 若需兼容，建议封装函数：
if runtime.GOOS == "windows" { mode = 0666 } else { mode = 0600 }
批量递归修改权限时最常漏掉的判断
用 filepath.WalkDir 遍历时，不区分文件与目录直接 Chmod(path, 0600)，会把目录权限也设成 0600 —— 缺少执行位（x）意味着无法 cd 进入、ls 查看，整个子树变“不可达”。
- 对每个
dirEntry调用entry.Type().IsDir()分流：目录用0755，普通文件用0600 - 跳过特殊类型：
entry.Type() & os.ModeType != 0（如 socket、pipe、device） - 用
os.Lstat替代os.Stat，避免遍历时因符号链接指向不存在路径而中断
真正难的从来不是调用 Chmod 这一行代码，而是搞清你到底想改谁的权限、在哪种上下文里生效、以及失败时系统到底在拒绝什么——这些细节藏在 os.Stat 返回的 FileInfo 和运行时环境里，不在文档第一行。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
