std::filesystem::status().permissions() 返回位掩码，需用位与判断权限，如 (st.permissions() & perms::owner_exec) != perms::none；跨平台需结合扩展名；挂载选项等系统限制也影响实际可执行性。
std::filesystem::status() 返回的 perms 怎么解析
直接用 std::filesystem::status(path).permissions() 拿到的是一个 std::filesystem::perms 枚举值，它本质是位掩码（bitmask），不是布尔开关。你不能拿它和 owner_exec 直接比较相等，得用位与运算判断是否“包含”该权限。
-
perms::owner_exec表示文件所有者有执行权，但这个值只是某一位为 1 的整数（比如 0x10），不是唯一状态 - 正确写法是：
(st.permissions() & perms::owner_exec) == perms::owner_exec，或者更常用、更安全的(st.permissions() & perms::owner_exec) != perms::none - 如果只检查“是否可执行”，通常要同时看 owner/group/others 三类里的任意一个 exec 位——毕竟只要当前用户属于其中一类且对应位开启，就能运行
为什么 stat() 和 filesystem::status() 结果可能不一致
Linux/macOS 下，std::filesystem::status() 底层调用 stat() 系统调用，但 C++ 标准库对符号链接的处理策略会影响结果：默认情况下，status() 不解引符号链接（类似 lstat），而 symlink_status() 明确强调这一点；如果你要检查目标文件权限，得先用 canonical() 或 read_symlink() 解析路径，再查状态。
- 常见错误现象：
status("a.sh")返回的权限是符号链接自身的（通常是 0777），而非它指向的脚本文件的真实权限 - 真实使用场景：部署脚本需确认某个 bin 路径最终能否执行，必须 resolve 后再 check
- 性能影响：
canonical()可能触发多次磁盘访问，路径很深或含大量软链时明显变慢
跨平台检查可执行权限的最小可靠写法
Windows 没有“可执行权限位”概念，perms::owner_exec 在那里恒为 false；但 Windows 仍可通过文件扩展名（如 .exe/.bat/.cmd）或尝试 CreateProcess 判断是否“能运行”。C++20 标准库不处理这层语义，所以纯 filesystem 方案在 Windows 上会漏判。
- 若只需 POSIX 兼容环境（Linux/macOS），直接检查
owner_exec | group_exec | others_exec三位即可 - 若需支持 Windows，必须额外判断扩展名：
path.extension() == ".exe" || path.extension() == ".bat" || ... - 注意
path.extension()返回的是".exe"（带点），不是"exe"；用path.has_extension()前先确保路径合法，否则抛filesystem_error
容易被忽略的权限继承与挂载选项影响
即使 perms::owner_exec 为 true，文件也可能实际无法执行——常见于 noexec 挂载的文件系统（如 /tmp 默认 noexec）、容器中 rootfs 被 remount 为 noexec、或 NFS 挂载时服务端禁用了执行位传递。
立即学习“C++免费学习笔记（深入）”；
- 这类限制无法通过
status()发现，只能靠运行时失败捕获（如execve()返回 EACCES） - 调试时看到权限位正常但
./script.sh报 “Permission denied”，第一反应不该是代码读错权限，而是mount | grep $(dirname path)查挂载参数 - CI/CD 环境尤其容易中招：Docker 默认以 noexec 挂载 /tmp，某些 runner 的工作目录也如此
