Windows 下 CreateSymbolicLink 失败主因是权限不足和路径格式错误：需管理员权限、源目标均用绝对路径、源路径不能以结尾、须明确指定文件或目录标志。
Windows 下用 CreateSymbolicLink 创建软链接（快捷方式）失败的常见原因
多数人卡在权限和路径格式上。CreateSymbolicLink 默认要求管理员权限，且目标路径不能是相对路径（哪怕当前目录下也不行），源路径也不能带尾部反斜杠。
- 必须以管理员身份运行程序，否则返回
ERROR_PRIVILEGE_NOT_HELD - 目标路径（即你要指向的原文件）要用绝对路径，推荐用
GetFullPathName转换 - 源路径（即快捷方式位置）也必须是绝对路径，且不能以
结尾（否则函数直接返回失败） - 第三个参数要明确传
SYMBOLIC_LINK_FLAG_FILE（文件）或SYMBOLIC_LINK_FLAG_DIRECTORY（目录），不能靠猜测
Linux/macOS 用 symlink 创建软链接时要注意路径语义
symlink 的第一个参数是“目标”，第二个是“新链接名”，但这个“目标”是相对于链接所在位置解析的，不是创建时的当前目录——这点极易误解。
- 如果想让链接在任意位置都能工作，目标路径应写成相对路径（比如
../bin/myapp）或绝对路径（如/usr/local/bin/myapp） - 写成
./myapp是错的：链接建好后，只要不在同一目录打开它，就会失效 - 硬链接（
link）不能跨文件系统，也不能用于目录；软链接可以，但目标不存在时链接仍能创建（只是变成“断链”） - 用
readlink -f可检查软链接是否有效，比ls -l更可靠
C++ 跨平台创建软链接的现实取舍
标准 C++ 没有 symlink 接口，C++17 的 std::filesystem::create_symlink 看似完美，但实际受限严重：
- MSVC 2019+ 在 Windows 上默认禁用 symlink 支持，需手动开启开发者模式或以管理员运行，否则抛出
std::filesystem::filesystem_error - Clang/libc++ 在 macOS 上对符号链接支持良好，但在某些旧 Linux 发行版（如 CentOS 7）可能因内核或 libc 版本太低而静默失败
- 如果你只控制部署环境，直接调系统 API 更稳；如果做通用库，建议 fallback 到复制或提示用户手动操作，别硬扛
误用 hard link 替代快捷方式的典型后果
硬链接不是快捷方式，它是同一 inode 的多个入口，删掉原文件不影响硬链接内容——这恰恰是很多人想要“快捷方式”时却选错方案的根本原因。
立即学习 “C++ 免费学习笔记（深入）”；
-
link或std::filesystem::create_hard_link无法跨分区 / 挂载点，Device or resource busy是常见错误 - 硬链接不能指向目录（Linux 不允许，Windows NTFS 的硬链接目录是另一套机制，不兼容 POSIX）
- 修改硬链接任一副本，所有副本内容同步变化（因为共享数据块），这不是“快捷方式”的行为逻辑
- 备份工具、IDE 文件监视器常把硬链接当成独立文件处理，导致重复扫描或误判变更
