std::filesystem::status() 不返回隐藏状态，因为其 file_status 仅封装 POSIX 权限和基础类型，不包含 Windows 的 FILE_ATTRIBUTE_HIDDEN 等平台特有属性；需用 GetFileAttributesW 单独获取。
用 std::filesystem::status() 读取文件属性时，为什么得不到隐藏状态？
std::filesystem::status() 返回的是 std::filesystem::file_status，它只封装了 POSIX 风格的权限位（如 owner_read、directory）和基础类型（regular、symlink 等），**不包含 Windows 的「隐藏」（hidden）、「系统」（system）、「只读」（readonly）等扩展属性**。这是标准库有意为之的设计：C++20 的 std::filesystem 抽象层默认不暴露平台特有属性，避免可移植性污染。
所以你调用：
auto st = std::filesystem::status("test.txt");
// st.permissions() 只告诉你是否可写/可执行，不会告诉你它是不是 Windows 下的隐藏文件
——这根本不是 bug，而是 spec 行为。
Windows 下真正判断隐藏属性，得绕过 std::filesystem 调用 GetFileAttributesW
Windows 的隐藏属性（FILE_ATTRIBUTE_HIDDEN）存储在文件元数据中，需通过 Win32 API 获取。C++ 标准库没提供跨平台接口，只能条件编译处理：
立即学习“C++免费学习笔记（深入）”；
- 在 Windows 平台，用
GetFileAttributesW检查返回值是否包含FILE_ATTRIBUTE_HIDDEN - 注意传入路径必须是宽字符（
std::wstring），推荐用std::filesystem::path::native()转换 - Linux/macOS 没有「隐藏属性」概念，通常靠文件名前缀
.判断，但这属于约定而非文件系统属性
示例：
#ifdef _WIN32
#include <windows.h>
bool is_hidden_win(const std::filesystem::path& p) {
DWORD attr = GetFileAttributesW(p.c_str());
return (attr != INVALID_FILE_ATTRIBUTES) &&
(attr & FILE_ATTRIBUTE_HIDDEN);
}
#endif
std::filesystem::status() 底层在 Windows 上到底做了什么？
以 libstdc++（GCC）和 MSVC STL 为例：status() 在 Windows 下实际调用的是 GetFileAttributesExW 或 FindFirstFileW，但**只提取其中能映射到 POSIX 语义的部分**：
- 文件是否存在 → 映射为
file_status构造成功与否 - 是否是目录 → 对应
FILE_ATTRIBUTE_DIRECTORY - 是否是符号链接 → 依赖
FILE_ATTRIBUTE_REPARSE_POINT+ 判定 tag - 隐藏、系统、归档、加密等属性一律丢弃，不参与 status 构造
也就是说，即使底层 Win32 调用拿到了完整属性，标准库实现也主动过滤掉了非标准化字段。这不是性能优化，是抽象边界控制。
跨平台判断“逻辑隐藏”：别只盯属性，看场景
所谓“隐藏”，语义取决于使用场景。不能只依赖一个 flag：
- 资源管理器级隐藏 → Windows 查
FILE_ATTRIBUTE_HIDDEN；macOS 查com.apple.FinderInfo中的hiddenbit（需getattrlist） - Shell / CLI 工具（如
ls）认为隐藏 → 文件名以.开头（.gitignore），与属性无关 - 构建系统（CMake、Meson）跳过 → 通常靠 glob 模式（
**/.*/）或白名单，而非系统属性
如果你在写一个跨平台配置扫描器，更靠谱的做法是组合判断：is_hidden_win(p) || p.filename().string()[0] == '.'，而不是执着于某个统一 API。
真正容易被忽略的是：**隐藏属性可以被用户手动修改（比如右键 → 属性 → 勾选“隐藏”），但文件名前缀不会变；而很多工具（包括 Git）只认点文件名。两者不等价，混用会漏判或误判。**
