std::filesystem::status() 返回 status_unknown 的根本原因是它仅依赖路径元数据访问，不穿透目录或解析链接；当路径不存在、父目录缺执行权限、跨挂载点不支持原子 stat 或为符号链接（Windows 默认不解析）时，即退化为未知状态。
用 std::filesystem::status() 读取文件基础属性时，为什么返回的 file_status 常是 status_unknown？
常见现象：调用 std::filesystem::status("path") 后，.type() 返回 file_type::none 或 file_type::status_unknown，.permissions() 看似有效但实际不可靠。
根本原因不是代码写错，而是 status() 不访问文件内容，只查路径本身的元数据——如果路径不存在、权限不足（如无执行权导致无法进入目录）、或跨挂载点且系统不支持原子 stat（如某些 NFS 配置），它就会退化为未知状态。
- 务必先用
exists(path)或is_regular_file(path)确认路径可达，再调status() - Linux/macOS 下若对父目录只有读权限（
r--）而无执行权（--x），status()无法穿透目录获取子项信息，会直接失败 - Windows 上对符号链接默认不解析，
status()返回的是链接自身属性；需改用symlink_status()显式区分
permissions() 返回的值怎么映射到 Unix 八进制权限（如 0755）？
std::filesystem::perms 是位掩码枚举，底层值与 POSIX stat.st_mode 的权限段对齐，但需手动屏蔽非权限位（如文件类型位）。
正确提取方式是：先用 static_cast<:uint32_t>(st.permissions()) & 0777</:uint32_t>，再按三位一组解释——不是直接输出该整数，因为高位可能含 owner_all、group_all 等组合常量，其值不等于原始 mode。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
-
perms::owner_read对应八进制400，perms::owner_write是200，perms::owner_exec是100 - 组合如
perms::owner_all=400|200|100=700，但它的枚举值在标准中未规定为 700，依赖实现；必须用位与0777安全截取 - 注意：Windows 不原生支持执行权限，
owner_exec等在 NTFS 上仅由扩展属性模拟，permissions()可能始终返回perms::owner_read | perms::owner_write
如何可靠判断“文件是否可执行”？
不能只看 status().permissions() & perms::owner_exec —— 这只是元数据标记，不代表系统真能执行。真正可靠的判断是尝试 access(path.c_str(), X_OK)（POSIX）或 GetFileAttributes() 检查 FILE_ATTRIBUTE_DIRECTORY 外加扩展名白名单（Windows）。
- Linux/macOS：
#include <unistd.h>，用access(path.c_str(), X_OK) == 0，它走内核权限检查，比读permissions()更准 - Windows：
std::filesystem::path的扩展名（.extension()）比权限位更关键；.exe、.bat、.ps1才可能执行，权限位基本忽略 -
std::filesystem::can_execute(path)并不存在——C++20 标准没提供运行时可执行性探测接口，必须平台适配
获取修改时间、大小等非权限字段，为什么有时 last_write_time() 报 std::filesystem::filesystem_error？
错误信息通常是 "Operation not permitted" 或 "No such file or directory"，即使 exists() 返回 true。这是因为 last_write_time() 和 file_size() 底层调用 stat()，而某些场景下 stat() 会失败：
- 路径是挂载的网络文件系统（如 CIFS/Samba），服务端禁用了时间戳访问
- 文件被其他进程以独占模式打开（Windows 常见），导致内核拒绝提供元数据
- 使用了
std::filesystem::directory_iterator遍历时，直接对iter->path()调last_write_time()比调iter->status().last_write_time()更容易出错——后者复用迭代器已缓存的stat结果
实战建议：批量处理时优先用 directory_entry::last_write_time()，避免重复系统调用；单文件则包裹 try/catch 捕获 filesystem_error，降级返回默认值（如 epoch 时间）。
