Windows用GetFileAttributes检查FILE_ATTRIBUTE_HIDDEN标志判断隐藏属性，需先校验是否为INVALID_FILE_ATTRIBUTES；Linux则依赖文件名以.开头的命名约定，二者语义不同、不可跨平台统一。
Windows平台下用GetFileAttributes检查隐藏属性
在Windows上，判断文件是否为系统隐藏文件，本质是检查其文件属性中是否包含FILE_ATTRIBUTE_HIDDEN标志。最直接的方式是调用Win32 API GetFileAttributes，它返回一个整型掩码，需用位运算判断。
注意：GetFileAttributes对不存在的路径会返回INVALID_FILE_ATTRIBUTES（即-1），必须先校验返回值，否则位运算结果无意义。
- 示例代码片段：
DWORD attrs = GetFileAttributes(L"C:\temp\secret.txt"); if (attrs == INVALID_FILE_ATTRIBUTES) { // 文件不存在或权限不足 } else if (attrs & FILE_ATTRIBUTE_HIDDEN) { // 是隐藏文件 } -
FILE_ATTRIBUTE_HIDDEN仅表示“用户隐藏”，不区分是否由系统设置；若还需排除系统/只读/目录等组合属性，需额外按位与判断 - 路径必须是绝对路径或当前工作目录下的相对路径；Unicode宽字符版本（
GetFileAttributesW）推荐优先使用
Linux/macOS没有“隐藏文件”系统属性，靠文件名前缀判断
类Unix系统没有文件系统级的隐藏属性，所谓“隐藏”纯属shell约定：以.开头的文件名（如.gitconfig）被默认忽略显示。C++程序无法通过stat属性获取该状态，只能检查文件名本身。
这意味着：即使stat()返回的st_mode里没有任何特殊标志，只要名字以.开头，就视为“隐藏”。但要注意，这不等于Windows的FILE_ATTRIBUTE_HIDDEN语义——它不阻止访问，也不影响系统行为。
立即学习“C++免费学习笔记（深入）”；
- 用
std::filesystem::path::filename()提取文件名，再用.string()[0] == '.'判断（需确保非空） - 不要依赖
stat().st_mode & S_ISVTX等误判：这些是粘滞位、setuid等权限位，和隐藏无关 - 某些桌面环境（如GNOME）会读取
.hidden文件来控制显示，但这属于应用层约定，stat或readdir完全感知不到
跨平台封装时别混淆“隐藏”和“不可见”的概念
写通用函数时，容易把Windows的属性判断和Linux的命名约定强行统一成一个is_hidden()接口。问题在于：二者语义不同、可变性不同、权限模型也不同。
比如，用户可在Windows资源管理器里取消勾选“隐藏受保护的操作系统文件”，导致FILE_ATTRIBUTE_SYSTEM | FILE_ATTRIBUTE_HIDDEN的文件突然可见；而Linux下改名就能让.bashrc立刻“现身”，无需任何API调用。
- 如果业务逻辑真需要统一抽象，建议分层处理：底层按平台原生方式判断，上层加注释说明“此隐藏仅为UI提示用途”
- 避免在Linux下调用
GetFileAttributes（编译不过）或在Windows下只查文件名前缀（漏掉真实隐藏属性） - 第三方库如Boost.Filesystem不提供
is_hidden()，正是因为它无法给出跨平台一致定义
容易被忽略的权限与符号链接边界情况
即使属性或命名满足隐藏条件，实际能否判断还取决于权限。例如：Windows下若进程无权读取文件属性（如NTFS ACL拒绝），GetFileAttributes会失败；Linux下若目录不可执行（noexec或chmod -x），连readdir都进不去，更别说检查文件名。
- 符号链接目标是否隐藏，不影响链接自身——
GetFileAttributes默认解析链接，GetFileAttributesEx加GET_FILEEX_INFO_LEVELS::GetFileExInfoStandard可选不解析；Linux下lstatvsstat同理 - Windows的
FILE_ATTRIBUTE_HIDDEN可被普通用户任意设置/清除；Linux的.前缀可被任意重命名修改——二者都不是安全机制 - 容器或沙箱环境（如WSL2、Flatpak）可能拦截或虚拟化这些API调用，返回值未必反映真实文件系统状态
