Linux中st_mode需先&0777提取权限位，再右移分组取低3位得三位八进制数；Windows不适用此逻辑。
Linux 文件权限的八进制值怎么对应到 C++ 的 stat 结构体？
直接看 st_mode 字段：它不是“存着八进制数”，而是按位存储的标志组合（如 S_IRUSR、S_IXGRP）。所谓“八进制掩码”（如 0755）只是人类方便书写和比对的一种表示方式，本质是三位八进制数对应三组 rwx 权限位。
转换的关键在于：从 st_mode 中提取权限位部分（去掉文件类型等杂项），再用位运算映射成 0–7 的每组数字。
实操建议：
-
st_mode & 0777是必须的第一步——屏蔽掉文件类型位（如S_IFDIR、S_IFREG），只保留权限位 - 然后分别右移并取低 3 位：
(mode >> 6) & 07得用户位，(mode >> 3) & 07得组位，mode & 07得其他位 - 不要用
printf("%o", mode)直接输出——它会把整个st_mode（含类型位）转成八进制，结果可能是100755这类非预期值
用 stat() 读取后如何安全转成三位八进制字符串（如 "755"）？
避免手拼字符串或依赖 locale；优先用整数计算再格式化。C++ 没有内置八进制权限解析函数，得自己拆解。
立即学习“C++免费学习笔记（深入）”；
示例逻辑（C++17 起可用）：
struct stat sb;
if (stat("path.txt", &sb) == 0) {
auto perm = sb.st_mode & 0777;
int owner = (perm >> 6) & 07;
int group = (perm >> 3) & 07;
int other = perm & 07;
char octal_str[4] = {0};
snprintf(octal_str, sizeof(octal_str), "%d%d%d", owner, group, other);
// octal_str 现在是 "755" 形式
}
注意点：
- 必须检查
stat()返回值，权限读取失败时st_mode值未定义 - 用
snprintf而非sprintf，防止缓冲区溢出 - 别用
std::format（C++20）直接格式化perm为八进制——它输出的是完整八进制表示（如755对应0755，但0100755类型位也会参与），仍需先 & 0777
为什么 chmod("file", 0755) 能生效，但反过来从 st_mode 提取时却不能直接用 0755 比较？
因为 chmod 的第二个参数就是“纯权限掩码”，内核自动忽略高位；而 stat 返回的 st_mode 是“全量模式字”，包含文件类型（高 4 位）、设置位（S_ISUID 等）和权限位。
常见错误现象：
- 写
if (sb.st_mode == 0755)—— 永远不成立，除非是特殊设备文件且没设置任何额外位 - 写
if ((sb.st_mode & 0777) == 0755)—— 正确，这才是权限等价判断 - 用
0755初始化变量再传给chmod没问题，但拿它跟st_mode原值比较就是错的
Windows 下能用这套逻辑吗？
不能。Windows 没有 POSIX 权限模型，stat() 在 MinGW/MSVC 中返回的 st_mode 是模拟值（仅区分只读/可写），0777 掩码无意义，S_IRUSR 等宏可能未定义或恒为 0。
跨平台代码要加条件编译：
- Linux/macOS：用
& 0777+ 位移提取 - Windows：通常跳过权限解析，或改用
GetFileAttributes()查FILE_ATTRIBUTE_READONLY - 若用
boost::filesystem::status()，其permissions()方法返回的是抽象枚举，不暴露八进制细节
真正容易被忽略的是：很多开发者在容器或 CI 环境中测试时默认用 Linux，但本地开发机是 macOS——两者 stat 行为一致，可一旦混入 Windows 构建节点，权限字段就彻底失效，且不会报错，只会静默返回错误值。
