必须用八进制常量（如0400）而非十进制小数字（如4），因为Unix权限位按所有者/组/其他三组高位对齐分布，0400对应第8位（所有者读），0004对应第2位（其他读），若混用十进制易导致位冲突和误判。
可以直接用 &、|、~ 三个运算符完成全部操作，不需要额外状态结构或循环。关键在于权限位必须互斥且可位移生成，比如 S_IRUSR 是 0400（八进制），不是随意选的整数。
为什么必须用八进制常量而不是十进制数字
Unix 文件权限的 9 位是分组设计的：所有者（3 位）、组（3 位）、其他（3 位），每组内 r/w/x 各占 1 位。系统头文件中定义的宏如 S_IRUSR 值为 0400（即十进制 256），它对应的是“所有者读”在 st_mode 中的**第 8 位**（从 0 开始计），不是第 0 位。
如果手动写成 1、2、4 这类低位值，会和“其他用户”权限（S_IROTH=0004）冲突，导致 st_mode & 4 既可能匹配“其他用户读”，也可能误判为“所有者执行”（因为 0100 也是 4 的八进制写法，但语义完全不同）。
-
0400、0200、0100是所有者权限，高位对齐 -
0040、0020、0010是组权限，中间三位 -
0004、0002、0001是其他用户权限，最低三位 - 直接用十进制 4 判断，无法区分是
0004还是0100，必须用完整掩码
检查权限时不能只写 if (mode & S_IRUSR)
这行代码本身没错，但容易忽略上下文：它只判断“是否设置了该位”，不等于“该权限生效”。实际使用中要结合文件类型和进程有效 UID/GID —— 比如目录没有 x 权限时，即使有 r 也无法 readdir()；又比如 setuid 程序运行时，S_ISUID 位会影响实际权限判定逻辑。
单纯位与只能回答“这个 bit 是不是 1”，不能替代完整的访问控制决策链。
- 正确姿势：
if ((st.st_mode & S_IRUSR) && !S_ISDIR(st.st_mode))（若需排除目录） - 更安全的做法是调用
access("path", R_OK)，它走内核真实权限检查路径 - 仅当明确做元数据解析（如 ls 命令实现）时，才直接用
&查掩码
chmod() 的 mode 参数怎么构造才不出错
传给 chmod() 的 pmode 是一个整数，但它代表的是**覆盖式写入**，不是增量更新。常见错误是把已有权限和新权限用 | 合并后传进去，结果清掉了不该清的位。
例如当前文件是 755（0755 八进制 = S_IRWXU|S_IRGRP|S_IXGRP|S_IROTH|S_IXOTH），你想加 S_IWGRP，不能写 old_mode | S_IWGRP 再传 —— 因为 old_mode 是从 stat() 读出的完整 st_mode，含文件类型位（如 S_IFREG），而 chmod() 只接受低 9 位的权限部分。
- 必须先提取权限位：
mode_t perm_bits = st.st_mode & 0777 - 再构造新权限：
mode_t new_perm = perm_bits | S_IWGRP - 最后调用：
chmod("file", new_perm) - 若要删权限，用：
mode_t new_perm = perm_bits & ~S_IWGRP
用 1u 定义自定义权限时要注意平台位宽
知识库里提到“最多 32 种权限”，这是基于 uint32_t。但实际 Unix st_mode 是 32 位整数，其中低 9 位固定给基础权限，高 23 位留给文件类型（S_IFREG 等）和特殊位（S_ISUID）。所以你不能把自定义权限塞进这 32 位里混用 —— 会破坏文件类型识别，stat() 可能返回 EBADF 或误判为非法 inode。
真正安全的做法是：自定义权限存单独字段（如数据库里的 user_perms int），和 st_mode 物理隔离；或者用更高位（如第 16–31 位）但必须确保所有操作函数都显式屏蔽掉这些位（& 0777）再喂给系统调用。
- 错误：
st.st_mode |= (1u —— 破坏 st_mode 结构 - 正确：
int app_perms = 0; app_perms |= (1u - Unix 权限和业务权限属于不同抽象层，硬塞一起迟早踩坑
