Windows下用GetFileAttributes检查FILE_ATTRIBUTE_HIDDEN标志位判断隐藏，需先验证返回值非INVALID_FILE_ATTRIBUTES；Linux/macOS则仅通过文件名是否以.开头判断，二者语义不同不可混用。
Windows下用GetFileAttributes检查FILE_ATTRIBUTE_HIDDEN
在Windows平台，C++判断文件是否隐藏最直接的方式是调用Win32 API GetFileAttributes，它返回一个位掩码，其中FILE_ATTRIBUTE_HIDDEN标志位为1即表示隐藏。
注意：该函数对目录同样有效，且不区分“系统隐藏”和普通隐藏——只要设置了该属性就算隐藏。
- 如果
GetFileAttributes返回INVALID_FILE_ATTRIBUTES，说明路径无效或无访问权限，不能直接用来判断隐藏状态 - 路径必须是绝对路径或当前工作目录下的相对路径；若含中文或特殊字符，建议用宽字符版本
GetFileAttributesW并传入std::wstring - 该API不解析NTFS的ACL或Reparse Point逻辑，仅看基础文件属性
// 示例：判断C: est.txt是否隐藏
DWORD attr = GetFileAttributes(L"C:\test.txt");
if (attr != INVALID_FILE_ATTRIBUTES && (attr & FILE_ATTRIBUTE_HIDDEN)) {
// 是隐藏文件
}
Linux/macOS没有“隐藏文件”概念，靠文件名前缀判断
类Unix系统没有文件系统级的隐藏属性，所谓“隐藏”只是shell约定：以.开头的文件或目录（如.gitconfig）默认被ls等工具忽略。
这意味着C++里无法通过stat()获取“隐藏”状态，只能手动检查文件名。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 用
std::filesystem::path::filename()取出最后一段名称，再用.string()[0] == '.'判断 - 注意：
.和..也符合该规则，但它们是特殊目录项，不是用户创建的“隐藏文件” - 某些GUI文件管理器（如macOS Finder）可能额外读取
.hidden文件或扩展属性，但标准C++不处理这些
// 示例：Linux/macOS风格判断
std::filesystem::path p = "/home/user/.cache";
if (p.filename().string().starts_with(".")) {
// 按惯例视为隐藏
}
跨平台代码要分条件编译，别硬套统一接口
试图写一个“通用is_hidden()”函数时，最容易犯的错是忽略平台语义差异：Windows的隐藏是元数据，Linux的是命名约定。强行抽象反而导致行为不一致。
- Windows下优先用
GetFileAttributes，不要依赖文件名 - Linux/macOS下只检查名字，不要尝试读取扩展属性（如
xattr），那不属于POSIX“隐藏”定义 - 如果项目需同时支持两种语义（比如备份工具要跳过所有隐藏内容），应明确拆分为
is_system_hidden()和is_convention_hidden()
std::filesystem::status可能返回权限错误，别当成隐藏依据
有人会想用std::filesystem::status(path).permissions()来间接推断——这是错的。隐藏和读写执行权限完全无关，且status()在路径不存在或无权限时抛std::filesystem::filesystem_error，错误码可能是no_such_file_or_directory或permission_denied，跟隐藏毫无关系。
- 调用
status()前务必先用exists()确认路径存在，否则异常会中断逻辑 -
permissions()字段里没有对应“隐藏”的枚举值，C++20标准也没加 - 即使你看到某个文件
status()调用失败，也不能反推它是隐藏的——更可能是路径错了或者没权限读父目录
INVALID_FILE_ATTRIBUTES就直接位与，结果把错误当成隐藏；而跨平台项目里又容易把Linux的.规则生搬进Windows逻辑，导致C:.config被误判——其实Windows根本不认这个前缀。 
