直接调用 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) 是提取这两类读权限是否存在，两者语义完全不同。

• 常用判断写法：(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 决定，和源文件无关。这是最常被忽略的隐式行为。

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

要保留权限，必须显式调用 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() 的返回为准。

C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！