Windows创建符号链接需开启开发者模式或策略权限，且dwFlags须匹配目标类型；路径须为绝对路径；源存在时不覆盖；C++17 std::filesystem支持跨平台链接但硬链接受限于文件系统和目录禁止。
Windows 上用 CreateSymbolicLink 创建软链接失败，权限和参数是关键
Windows 默认禁止普通用户创建符号链接，哪怕程序以管理员身份运行，也得显式开启开发者模式或启用“创建符号链接”策略。否则会直接返回错误 ERROR_PRIVILEGE_NOT_HELD 或 ERROR_ACCESS_DENIED。
调用 CreateSymbolicLink 时，第三个参数 dwFlags 必须根据目标类型选对：SYMBOLIC_LINK_FLAG_DIRECTORY 仅当目标是目录时才加；误加会导致对文件创建失败，且错误码不直观（常为 ERROR_INVALID_PARAMETER）。
- 路径字符串必须是绝对路径，相对路径会被静默截断或导致不可预知行为
- 目标路径不需要存在，但若不存在，链接将变成“悬空链接”，
GetFileAttributes会返回INVALID_FILE_ATTRIBUTES - 如果源路径已存在，API 不会覆盖，而是直接返回
FALSE，需先DeleteFile或RemoveDirectory
Linux/macOS 下 symlink 和 link 系统调用的 C++ 封装要点
C++ 标准库（C++17 起）提供了 std::filesystem::create_symlink 和 std::filesystem::create_hard_link，底层分别调用 symlink(2) 和 link(2)。但要注意：硬链接不能跨文件系统，也不能指向目录（Linux 内核禁止，EPERM）；软链接无此限制，但解析依赖于运行时路径上下文。
-
std::filesystem::create_hard_link的第一个参数是目标（已存在），第二个是新链接名 —— 和 shell 命令顺序相反，容易搞反 - 软链接内容（即
readlink读到的路径）是原样存储的，不做路径规范化；写入"../foo"就存"../foo"，不会转成绝对路径 - 若目标路径含空格或特殊字符，C++ 接口不额外转义，由文件系统原样处理；出问题优先检查路径字符串本身是否含非法控制符
硬链接 vs 软链接：inode、删除行为与实际可观察差异
硬链接共享同一个 inode，所有硬链接都是“平等”的文件名入口；删掉其中一个，只要还有其他硬链接存在，数据块就不会释放。而软链接是独立 inode，内容只是字符串路径，删掉目标后它就失效，ls -l 会显示红色闪烁（broken link）。
立即学习“C++免费学习笔记（深入）”；
- 用
stat命令看Links字段：硬链接数 >1 表示有多个硬链接指向该 inode；软链接自身Links永远是 1 -
du统计磁盘占用时，硬链接只算一次；软链接文件本身占几个字节（存路径字符串），不计入目标大小 - 修改文件权限/时间戳会影响所有硬链接；但改软链接的权限只影响链接文件本身，不影响目标
跨平台封装时最常被忽略的三个细节
想写一个统一接口自动选软/硬链接，光判断 OS 不够。Windows 的硬链接（CreateHardLink）只能用于同一卷（volume），且目标必须是文件；而 Linux 的 link(2) 对目录直接失败。这些约束在编译期无法检查，全靠运行时报错。
- 不要假设
std::filesystem::create_hard_link在 Windows 上能链目录 —— 它会失败并抛std::filesystem::filesystem_error，错误码对应ERROR_NOT_SUPPORTED - 软链接的目标路径如果是相对路径，其解析基准是链接所在目录，不是当前工作目录 —— 这点和 shell 中
cd后执行ln -s的直觉不同 - 容器或沙箱环境（如 Docker、WSL2）中，宿主机挂载进来的路径可能无法创建硬链接，因为文件系统边界被虚拟化了，此时应降级为软链接并记录警告
真正麻烦的从来不是调哪个函数，而是链接创建后谁在什么时候、以什么路径去访问它 —— 路径解析时机、挂载点变化、用户态 symlink 层（如某些杀毒软件重定向）都会让结果偏离预期。
