最可靠的方式是用 std::filesystem::status() 获取文件属性，但权限需通过 permissions() 提取并按位判断，且它返回的是符号链接自身而非目标的权限；路径必须存在，否则可能抛异常或返回 none；跨平台时注意 windows 不支持 owner_exec 等 posix 权限位。
直接说结论：用 std::filesystem::status() 获取文件系统属性最可靠，但权限位需额外处理——它返回的 file_status 对象里权限信息藏在 permissions() 成员函数中，且默认不包含符号链接目标权限（这点极易踩坑）。
为什么 status() 返回的权限总是 no_perms 或 unexpected？
常见错误是传入了悬空符号链接或路径不存在，status() 会抛出 std::filesystem::filesystem_error 或返回 file_type::none；更隐蔽的问题是：若路径是符号链接，status() 返回的是链接本身的元数据（如链接文件的权限），而非它指向的目标。这和 symlink_status() 行为一致，但很多人误以为它会自动解引用。
- 检查路径是否存在：
exists(p)必须为 true，否则status(p)可能失效 - 区分用途：要目标权限用
status(p)，要链接自身权限用symlink_status(p) - 捕获异常比检查
file_type更稳妥，尤其在多线程或 NFS 挂载路径下
如何正确提取并解读 permissions() 的值？
status(p).permissions() 返回 perms 枚举值，本质是位掩码，不能直接打印或比较字面量。C++17 不提供内置字符串化支持，需手动按位判断。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 常用权限位：
owner_read、owner_write、owner_exec、group_read等，都在std::filesystem命名空间下 - 判断写权限：
(st.permissions() & perms::owner_write) == perms::owner_write（必须用等值判断，不能只用&） - 注意：Windows 下部分权限位（如
group_exec）恒为 false，sticky_bit也无意义
示例：
auto st = status("/etc/passwd");<br>if (st.type() == file_type::regular) {<br> auto p = st.permissions();<br> bool readable = (p & perms::owner_read) == perms::owner_read;<br> bool executable = (p & perms::owner_exec) == perms::owner_exec;<br>}
status() 在不同平台的行为差异与兼容性陷阱
Linux/macOS 下 status() 能完整反映 POSIX 权限；Windows 下仅映射基本读/写/隐藏/系统属性，且 perms::owner_exec 永远为 false（可执行性由扩展名或 ACL 决定）。
- 跨平台代码不要依赖
owner_exec判断可执行性，改用is_regular_file()+ 文件扩展名启发式判断 - Windows 上
status()可能返回file_type::unknown（如访问网络驱动器失败时），需 fallback 处理 - 某些 FAT32 卷不支持权限位，
permissions()总是perms::owner_read | perms::owner_write
真正难的不是调用 status()，而是理解它返回的权限到底属于谁、在什么文件系统上有效、以及当它“看起来没权限”时——到底是路径错了、链接坏了，还是平台根本不支持这个位。别急着封装成一行工具函数，先用 file_type 和 permissions() 分开打日志看两眼。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
