std::filesystem::hard_link_count返回值常为1，主因是文件系统不支持硬链接（如NTFS默认禁用、exFAT/FAT32不支持）或Windows下API回退机制；应通过ls -li（Linux/macOS）或fsutil hardlink list（Windows）交叉验证，跨平台使用需加兜底逻辑。
std::filesystem::hard_link_count 返回值总是 1？
多数情况下不是代码写错了，而是当前文件系统不支持硬链接（比如 NTFS 默认禁用、exFAT/FAT32 根本不支持），或者你查的是 Windows 上的普通文件——std::filesystem::hard_link_count 在 Windows 上依赖 GetFileInformationByHandle，而该 API 对非 NTFS 卷或无权访问的文件会回退为返回 1。
- Linux/macOS 下只要文件系统支持（ext4、XFS、APFS），且文件确实有多个硬链接，
hard_link_count就能正确返回真实数量 - Windows 下仅 NTFS + 启用硬链接权限（需管理员创建，且目标卷未禁用）才可能非 1；普通用户用
mklink /H创建后仍可能看到 1，因为某些反病毒软件或组策略会拦截底层链接计数读取 - 不要用它判断“文件是否被其他进程打开”——那是引用计数或句柄问题，和硬链接无关
怎么确认文件真有多个硬链接？
别只信 C++ 代码结果，先用系统命令交叉验证：
- Linux：运行
ls -li，看同一行 inode 号是否出现在多个文件路径里；或直接stat filename查Links:字段 - macOS：同 Linux，
stat -f "%l %N" path输出链接数和名字 - Windows：需管理员权限运行
fsutil hardlink list <file>，若报错“不支持此操作”，说明卷不支持硬链接
如果命令显示链接数 >1，但 std::filesystem::hard_link_count 仍返回 1，基本可锁定是 libstdc++/libc++ 的实现缺陷或编译时未启用完整 filesystem 支持（如 GCC 9+ 需链接 -lstdc++fs）。
跨平台代码里要不要依赖 hard_link_count？
要，但得加兜底逻辑——它不是高危函数，但可靠性受制于 OS 和 FS，不能当作原子性保证。
立即学习“C++免费学习笔记（深入）”；
- 仅用于辅助判断（例如“这个配置文件是否被多个服务共用”，而非“必须等链接数降为 1 才删除”）
- Linux 下可放心用；Windows 下建议先检查
std::filesystem::status(path).type()是否为std::filesystem::file_type::regular，再调用，避免对目录或符号链接误用 - 注意：C++20 前该函数在部分标准库中是实验性接口，MSVC 19.28+、GCC 10+、Clang 12+ 才稳定支持；旧版本可能静默返回 0 或抛
std::filesystem::filesystem_error
常见错误：把 symbolic link 当 hard link 数
std::filesystem::hard_link_count 完全不感知符号链接——它统计的是同一 inode 的目录项数量。符号链接是独立 inode，有自己的链接数，不影响目标文件的 hard_link_count。
- 执行
ln -s target linkname后，hard_link_count(target)不变 - 执行
ln target linkname（无 -s）后，hard_link_count(target)才 +1 - 误用
is_symlink()判断后就跳过hard_link_count，反而漏掉真正需要关注的硬链接场景
硬链接数量本身是个静态元数据，不随打开/关闭文件变化，也不反映当前内存映射状态。真正容易被忽略的是：它在容器、网络文件系统（NFSv3）、Wine 环境下行为不可控，生产环境做关键逻辑前，务必本地实测对应部署环境。
