C++里真能用create_hard_link造硬链接？别急，先看清它长什么样

刚在Windows上写完一段C++代码，想用CreateHardLinkW给某个日志文件建个硬链接，结果编译报错：identifier "create_hard_link" is undefined。翻了三遍文档才反应过来——C++标准库压根没有叫 create_hard_link 的函数。它不在 <filesystem> 里，也不在 <sys/stat.h> 中，更不是 MSVC 或 GCC 的扩展。这个名字，是很多人从 Python 的 os.link()、Linux 的 ln 命令，甚至某些中文技术博客里“顺手抄来”的幻觉。

硬链接这事，本身就不像软链接那么随和。它不存路径，不搞跳转，而是直接让两个（或多个）文件名指向同一个 inode（Windows 叫 MFT 记录）。删掉其中一个，只要还有别的名字指着它，数据就纹丝不动。但正因如此，硬链接有死规矩：只能在同一卷（同一分区）、不能跨设备、不能指向目录（Windows 和 Linux 都禁）、且目标必须已存在。

那在 Windows C++ 里到底怎么干？答案是：CreateHardLinkW（宽字符版）或 CreateHardLinkA（ANSI 版），来自 Windows API，头文件是 <windows.h>。它不是 C++ 的，是 Win32 的——这点得拎清。你得手动处理 Unicode 路径、检查返回值、配好权限，还得确保调用进程有“绕过遍历检查”特权（对 NTFS 卷上的某些路径而言）。

写法很直白：

#include <windows.h>
#include <iostream>

bool make_hard_link(LPCWSTR link_name, LPCWSTR target_name) {
    if (CreateHardLinkW(link_name, target_name, nullptr)) {
        return true;
    }
    DWORD err = GetLastError();
    std::wcerr << L"硬链接失败，错误码：" << err << L"\n";
    return false;
}

// 用法示例
make_hard_link(L"D:\\backup\\config.dat", L"C:\\app\\config.dat");

注意三点：

• link_name 必须不存在，系统不会覆盖；
• target_name 必须已存在且可访问，不能是目录，也不能是符号链接终点（即得是“真身”）；
• 两个路径必须在同一个 NTFS 卷上，比如 C:\ 和 D:\ 之间绝对不行，哪怕物理硬盘只有一块。

有人试过 FAT32？直接失败——硬链接是 NTFS 特性，FAT32、exFAT、ReFS（旧版）都不支持。你可以用 GetVolumeInformationW 检查卷格式，避免 runtime 才踩坑。

再聊聊权限。普通用户在自己的目录下建硬链接通常没问题，但如果目标在 C:\Windows 或受保护的系统位置，大概率会收到 ERROR_PRIVILEGE_NOT_HELD（错误码 1314）。这不是权限设置错了，而是你缺一个叫 “SeCreateHardLinkPrivilege” 的用户权限。开发时建议避开系统目录，生产环境若真需要，得用 AdjustTokenPrivileges 提权——但别轻易动它，安全模型不是摆设。

还有一点常被忽略：硬链接不继承父目录的 ACL，而是完全复刻目标文件的 DACL 和 SACL。也就是说，你新建的链接，权限和原文件一模一样。如果原文件权限收紧了，所有硬链接同步生效；反之亦然。这跟软链接不同——软链接的权限看的是链接文件自身（通常是 644），而硬链接根本没“自身权限”这回事，它就是原文件。

实际项目中，硬链接适合什么场景？我们团队用它做过两件事：一是日志归档时，把当天的 app.log 同时挂到 logs/2024-06-15.log 和 logs/latest.log 下，避免写两次磁盘；二是单元测试中快速构造“多入口但同数据”的测试文件集，省去拷贝开销。但它绝不适合做配置切换或版本别名——因为修改任一链接，等于修改全部，毫无隔离性。

最后提醒一句：<filesystem>（C++17）里的 std::filesystem::create_hard_link 确实存在，但MSVC 从 19.30（VS 2022 17.0）才开始稳定支持，GCC 12+ 在 Windows 上仍依赖 MinGW-w64 补丁，Clang 更慢半拍。如果你的构建环境较老，别迷信标准库接口，老老实实用 CreateHardLinkW 更靠谱。

硬链接不是银弹，但它安静、高效、零额外存储。用对地方，它比任何脚本都可靠；用错前提，它会让你在凌晨三点对着“文件消失了却还能读”的现象发呆。理解它的边界，比记住函数名重要得多。

下次看到 create_hard_link，先问一句：这是谁家的孩子？在哪儿出生？能活在哪个系统上？——问题清楚了，代码自然就稳了。