windows用getfileattributes检查file_attribute_hidden位判断隐藏属性，linux/macos则依赖文件名以.开头或.hidden文件约定，跨平台需按场景明确定义“隐藏”语义。
Windows下用GetFileAttributes判断FILE_ATTRIBUTE_HIDDEN
Windows系统里，文件是否被标记为“隐藏”属性，本质是读取其文件属性位。核心函数是GetFileAttributes，它返回一个DWORD值，每个bit代表一种属性（如只读、系统、隐藏等）。只要检查FILE_ATTRIBUTE_HIDDEN这个flag是否被置位即可。
注意：该函数不区分“用户手动设的隐藏”和“系统自动生成的隐藏”（比如desktop.ini），只要属性位存在就返回true；也不管文件是否在资源管理器中实际可见（比如“显示隐藏文件”开关关闭时用户看不到，但属性本身没变）。
-
GetFileAttributes返回INVALID_FILE_ATTRIBUTES说明路径无效或无访问权限，必须先检查这个错误码，不能直接按位与 - 路径要用宽字符（
LPCWSTR），传入窄字符串会返回错误——哪怕你用的是ANSI版本GetFileAttributesA，也得确保编码匹配（推荐统一用UTF-8 +MultiByteToWideChar转换） - 符号链接（快捷方式）本身的属性和目标文件无关，
GetFileAttributes查的是链接文件自身，不是它指向的内容
Linux/macOS没有对应“隐藏属性”，但有约定俗成的点开头文件名
Linux和macOS内核不提供类似Windows的“隐藏属性”元数据字段。所谓“隐藏”，纯属shell和GUI文件管理器（如Nautilus、Finder）的约定：以.开头的文件或目录默认不显示（ls需加-a才列出）。
这意味着：不存在系统级API能“读取隐藏标记”，只能检查文件名是否符合.开头规则。但要注意几个现实偏差：
- 某些桌面环境（如GNOME）支持
.hidden文件——在目录下放一个内容为文件名列表的.hidden，就能让这些条目不显示；这完全由用户态程序解析，C++代码无法通过stat或open得知 - macOS还有扩展属性
com.apple.FinderInfo，其中有个bit控制Finder是否隐藏，但这是私有机制，且仅影响Finder，终端命令不受影响；读取它需要getxattr并解析二进制结构，非常脆弱，不建议依赖 - 不要用
stat()的st_mode去判断——权限位（如0644）和“隐藏”毫无关系
跨平台判断逻辑不能只靠一个函数
想写个“跨平台is_hidden()”，不能简单封装GetFileAttributes再加个str[0] == '.'就完事。真实场景下，你要明确“隐藏”的定义来源：
- 如果目标是模拟资源管理器行为（比如做同步工具，跳过用户标记的隐藏项），Windows必须查
FILE_ATTRIBUTE_HIDDEN，Linux/macOS必须检查.开头 + 当前目录是否存在有效的.hidden文件并解析它 - 如果只是避免处理临时文件，不如直接过滤常见模式：
.*、*~、#*#等，比纠结“系统标记”更可靠 - Qt或wxWidgets这类GUI框架提供了
QFileInfo::isHidden()，它们内部做了平台适配，但底层仍是上述逻辑——调用前确认你真需要GUI层抽象，还是直接系统API更可控
容易忽略的权限与符号链接陷阱
即使属性读取成功，结果也可能不可信：
- 普通用户对系统目录（如
C:\Windows）调用GetFileAttributes可能因UAC或ACL失败，返回INVALID_FILE_ATTRIBUTES，此时不能默认“未隐藏”，而应记录权限不足并跳过判断 - Linux下
stat()对符号链接默认返回链接自身信息；若想判断目标是否“隐藏”，得用lstat()读链接名，再readlink()拿到路径，最后检查目标文件名——但目标路径可能是相对路径或跨分区，解析复杂度陡增 - NTFS重解析点（如目录交接点）、Wine环境、网络驱动器（WebDAV/SMB）都可能让
GetFileAttributes返回意外值，尤其SMB共享常把服务器端的POSIX权限映射成Windows属性，FILE_ATTRIBUTE_HIDDEN可能被误设
真正难的从来不是“怎么读属性”，而是“读到的结果在当前上下文里到底意味着什么”。不同场景下，“隐藏”的语义边界模糊，硬套一个判断逻辑反而容易出错。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
