os.filemode是uint32类型，低9位存unix权限，高23位存文件类型标志（如os.modedir）；判断目录应使用fi.mode().isdir()，而非位运算；os.openfile的perm参数仅在o_create时生效，修改已有文件权限须调用os.chmod。
os.FileMode 不是纯权限数字，而是带类型标志的 uint32
很多人一看到 0644 就以为它和 Linux 的 chmod 数字完全等价，直接拿 os.FileMode(0644) 去做位运算或判断类型，结果出错。实际上 os.FileMode 是 uint32 别名，低 9 位存传统 Unix 权限（rwx），高 23 位存文件类型和属性标志（如 os.ModeDir、os.ModeSymlink）。0644 本身不带任何类型信息，它只是权限位；而 os.ModeDir | 0755 才表示“一个目录，权限为 rwxr-xr-x”。
常见错误现象：
-
os.FileMode(0644) | os.ModeDir看似合理，但语义混乱——0644是权限值，os.ModeDir是类型标志，二者不在同一抽象层 - 用
fi.Mode() == os.ModeDir判断目录，会漏掉权限位（实际值可能是0x80000000 | 0755） - 打印
fi.Mode()得到100644（八进制），误以为是 bug —— 其实是os.ModeRegular（0x8000十六进制 =0100000八进制）+0644的组合结果
判断文件类型该用 IsXXX() 方法，别手写位运算
Go 标准库早已封装好语义清晰的方法，直接调用比自己写位掩码更安全、可读性更强，也兼容 FAT/NTFS 等非 POSIX 文件系统。
- 判断是否为目录：
fi.Mode().IsDir()，不是fi.Mode() & os.ModeDir != 0 - 判断是否为普通文件：
fi.Mode().IsRegular() - 提取纯权限部分：
fi.Mode().Perm()，它只返回低 9 位，比如0644；而fi.Mode() & os.ModePerm虽然等效，但不如.Perm()直观 - 判断是否可执行：
fi.Mode().Perm() & 0111 != 0（注意是八进制0111，不是十六进制）
os.OpenFile 的 perm 参数只在创建时生效，且不改变已有文件
os.OpenFile(name, flag, perm) 的第三个参数 perm 完全被误解最多：它**不是“打开时的权限”**，而是“新建文件时的初始权限”。只要文件已存在，这个参数就被忽略。
- 若
flag不含os.O_CREATE，perm完全无作用 - 即使传了
0600，如果文件已存在且权限是0644，也不会被自动收紧 - umask 会影响最终权限：传
0666+ 当前 umask=0022 → 实际创建为0644；但 Go 不帮你做 umask 计算，你得自己预估或用os.FileMode(0666) &^ umask - Windows 下大部分权限位无效，仅影响可执行标记（通过
syscall.SetFileAttributes间接处理）
修改已有文件权限必须显式调用 os.Chmod
没有“原子性创建并设权”的 API。靠 os.OpenFile 一步到位是错觉；要确保权限准确，必须分两步：先创建（或打开），再 os.Chmod。
-
os.Chmod("x.log", 0600)是最常用写法，但失败不报错也不提示——需检查返回err - 失败主因：当前进程不是文件 owner（Chmod 不需要 root，但必须是 owner）；路径是符号链接（默认操作目标文件，不是链接本身）；权限值非法（如只传
0400而非完整三位八进制模式） - 想改符号链接本身的权限，得用
os.Lchmod（仅 Unix-like 系统支持） - 批量操作建议用
filepath.WalkDir配合os.Chmod，避免递归时权限不足中断
真正容易被忽略的是：权限变更不是“设置即生效”的魔法操作，它依赖操作系统层面的 owner 关系、umask 环境、文件系统语义。哪怕代码里写了 0600，在容器里跑、在 macOS APFS 加密卷上跑、在 NFS 挂载点上跑，行为都可能不同。别只测本地 Linux，得看部署环境的真实约束。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
