macOS 和 Linux 不支持“隐藏文件”语义，只能靠命名约定

与Windows不同，POSIX系统（包括macOS和Linux）压根没有“文件隐藏属性”这个概念。所谓的隐藏，完全是Shell（如bash、zsh）和图形化文件管理器（如Finder、Nautilus）之间的一种约定：任何以点号.开头的文件名，默认不予显示。因此，用C++在这些系统上无法直接“设置隐藏”，唯一的办法就是重命名文件，使其符合这个命名规则。

那么，具体该怎么操作呢？

立即学习“C++免费学习笔记（深入）”；

• 使用std::filesystem::rename函数，将"config.txt"重命名为".config.txt"即可实现隐藏；反之，去掉文件名开头的点号就能取消隐藏。
• 这里有个陷阱：重命名操作可能会因为跨文件系统而失败（例如试图从/tmp重命名到/home）。在这种情况下，需要先复制文件到目标位置，再删除原文件，并且要注意处理文件权限（可能需要同步执行chmod）。
• 切记，不要试图通过stat()或dirent结构体的某个字段来判断文件“是否隐藏”——这些系统接口根本不提供此类信息。判断隐藏的唯一标准，就是看文件名是否以.开头。

跨平台封装时别硬凑统一接口，优先隔离平台逻辑

很多开发者第一反应是封装一个统一的接口，比如set_hidden(const std::string& path, bool hidden)，然后在内部根据操作系统自动切换逻辑。想法很美好，但实际是个坑。举个例子，在macOS上对"log.txt"调用set_hidden(true)，实际生成的是".log.txt"；而在Windows上，文件原名不变，只是属性位被修改。这意味着，同一份配置文件路径，在不同平台下的实际文件名可能不同，极易导致后续读取逻辑失败。

更稳妥的做法是什么呢？

• 在业务逻辑层就明确区分“系统属性隐藏”和“命名约定隐藏”这两种语义。例如，日志目录在Windows上使用属性隐藏，在macOS/Linux上则统一创建在类似$HOME/.myapp/logs/这样的点号目录下。
• 如果必须提供一个统一的API，那么其返回值应该包含“操作是否真正生效”的信息。例如，在Linux下对一个非点号开头的文件调用set_hidden(true)，函数应返回false，并将errno设置为ENOTSUP（操作不支持）。
• 避免在编译时使用#ifdef __APPLE__这类宏，把三套平台的逻辑硬塞进同一个函数体里。这样做会导致调试时栈追踪信息混乱，一旦出问题，很难定位根源。

Qt 或 Boost.Filesystem 也解决不了根本差异

或许有人会想，借助Qt的QFile::setPermissions或者Boost的boost::filesystem::permissions，是不是就能优雅地跨平台了呢？答案是并不能。这两个库操作的分别是POSIX系统的文件权限位（读/写/执行）或Windows的ACL（访问控制列表），它们和“是否在文件管理器中显示”完全没有关系。Qt并没有暴露macOS Finder的扩展属性（如com.apple.FinderInfo）接口，而Boost库则根本不会处理以点号开头的命名约定。

所以，结论很明确：

• 对于Qt用户，在macOS/Linux上应该直接使用QDir::rename来重命名文件以实现隐藏。试图用QFile::setPermissions加上自定义属性是行不通的，不如老老实实用QProcess调用系统命令attrib +h（仅限Windows）。
• Boost用户也不要指望通过status().permissions()来读取文件的隐藏状态——它永远读不到，因为这个概念在底层就不存在。
• 所有宣称跨平台的文件系统抽象库，在这个具体场景下都只是“胶水”，底层的差异化逻辑仍然需要开发者自己按平台分别实现，没有捷径可走。

说到底，跨平台文件隐藏的难点，不在于功能实现，而在于概念上的根本错位：Windows有文件属性，而POSIX系统没有。最容易被忽略的一点是：你在Linux上写的“隐藏”代码执行后，用普通的ls命令确实看不见文件，但用ls -a命令则一览无余。而在Windows上，一旦用户在资源管理器里关闭了“显示隐藏的文件”选项，那么即便是dir /a:h这样的命令也需要手动输入才能看到。这种底层语义的断层，是无法通过一层简单的包装器来抹平的。