直接调用 std::filesystem::status(path).permissions() 获取解析后目标文件权限；需先验证 exists() 和 is_regular_file()，权限判断必须用位与（如 (p & perms::owner_read)），copy_file 不继承权限，需额外 permissions(dst, status(src).permissions(), perm_options::replace) 同步。
怎么用 std::filesystem::status() 拿到文件权限掩码
直接调用 std::filesystem::status(path).permissions()，别用 symlink_status() —— 后者对符号链接返回的是链接本身的权限，不是目标文件的。你想要的是实际可访问的那个文件的权限，status() 才做路径解析。
常见错误现象：permissions() 返回 perms::unknown，大概率是路径不存在、没读权限，或跨文件系统挂载导致 stat() 失败。先检查 exists() 和 is_regular_file()，避免后续位运算无意义。
-
std::filesystem::status()在 Windows 上会忽略部分 Unix 权限位（比如owner_write对只读文件表现为 set），但掩码值仍可安全用于位判断 - Linux/macOS 下返回的是
st_mode & 0777的映射，和ls -l显示一致；Windows 下则基于 ACL 折算，owner_read/owner_write是主要可用位 - 不要对目录路径直接拿权限去 open() —— 目录的执行位（
owner_exec）控制的是能否chdir或遍历，和文件读写无关
perms 位运算怎么写才不踩坑
权限是位集合，不是枚举值，必须用位与（&）判断，不能用 ==。比如判断是否可读：(p & perms::owner_read) == perms::owner_read，而不是 p == perms::owner_read —— 后者会漏掉同时有读+写的文件。
容易混淆的点：perms::owner_read | perms::group_read 是构造掩码，p & (perms::owner_read | perms::group_read) 是提取这两类读权限是否存在，两者语义完全不同。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 常用判断写法：
(p & perms::owner_read)非零即表示 owner 可读（C++17 起可直接当 bool 用） - 组合多个条件时，优先用括号明确优先级：
(p & (perms::owner_read | perms::group_read)) != perms::none - Windows 下
perms::owner_exec基本无效（exe 文件靠扩展名识别），但perms::owner_write仍可靠 —— 只读属性被设为 true 就对应这个位
为什么 copy_file() 不继承权限，以及怎么补
默认情况下，std::filesystem::copy_file(src, dst, copy_options::overwrite_existing) **完全不复制权限**，新文件权限由 umask 决定，和源文件无关。这是最常被忽略的隐式行为。
要保留权限，必须显式调用 permissions(dst, status(src).permissions(), perm_options::replace)，且注意：该函数在 Windows 上仅影响只读位，其他位会被忽略。
- 顺序不能错：先 copy，再 permissions；反过来可能因文件不存在而失败
-
perm_options::add和perm_options::remove适合增量修改，但想完全同步就得用replace - 若目标路径已有文件，
permissions()不会报错，但也不会改变所有权 —— 权限操作不涉及 uid/gid
跨平台权限处理的实际限制
别指望 std::filesystem::perms 能做细粒度 ACL 控制。它只映射传统 Unix rwx 和 Windows 只读标志，setuid/sticky 等位在 Windows 上无意义，在 Linux 上也可能被内核忽略（取决于挂载选项）。
真正需要兼容性时，优先关注三个位：owner_read、owner_write、owner_exec。其余如 group_*、others_* 在 Windows 上基本不可控，硬判断可能误导逻辑。
- macOS APFS 支持 ACL，但
std::filesystem不暴露接口，得回退到chmod()+sys/stat.h - 容器或沙箱环境（如 Flatpak）下，即使权限位显示可写，
open(O_WRONLY)仍可能因策略拒绝 —— 权限掩码只是第一道门，不是最终裁定 - 测试时别只用
touch创建文件：它的默认权限受 umask 影响，而ofstream创建的文件可能绕过 umask，行为不一致
权限位看起来简单，但跨平台时每个判断背后都连着系统调用和挂载策略。别依赖 perms 值做安全决策，它只是 stat 结果的薄封装，真实访问控制永远以 open() 或 fopen() 的返回为准。
