windows下createsymboliclink失败主因是权限限制，需管理员身份或启用开发者模式；跨平台应分层处理，优先std::filesystem::create_symlink，失败后按平台fallback并明确告知用户限制。
Windows下用CreateSymbolicLink失败：权限和管理员身份是硬门槛
直接调用CreateSymbolicLink在大多数用户场景下会返回ERROR_PRIVILEGE_NOT_HELD或ERROR_ACCESS_DENIED，不是代码写错了，而是Windows默认禁止普通用户创建符号链接。
- 必须以管理员身份运行进程（UAC提升），仅“以管理员身份运行IDE”不够，整个进程启动时就得带权限
- 从Windows 10 1703起可绕过：启用开发者模式后，普通用户也能创建
symlink（需组策略或Set-ExecutionPolicy DeveloperMode） -
CreateSymbolicLink第二个参数（目标路径）如果是相对路径，会被解析为相对于当前工作目录，不是相对于链接所在目录——这点和Linux行为不一致，容易导致链接失效
Linux/macOS用symlink函数要注意路径语义和错误码处理
symlink本身不检查目标是否存在，也不验证路径合法性，只做字符串绑定。常见误判是看到返回0就认为成功，其实得结合errno细看。
- 目标路径过长（超过
PATH_MAX）时返回-1且errno == ENAMETOOLONG，但很多CI环境或容器里PATH_MAX可能被裁剪，要预留余量 - 如果目标路径含
..或开头无/，创建的是相对符号链接；含完整绝对路径才是绝对链接——这直接影响后续readlink或stat行为 - Linux下对目录建符号链接需加
S_IFDIR标志（即symlink("target", "link");默认按文件处理，目录链接需额外判断并用symlinkat或mkdir + symlink组合）
跨平台封装时别硬套POSIX语义，std::filesystem::create_symlink不是银弹
C++17的std::filesystem::create_symlink看似统一，但它在Windows上底层仍调用CreateSymbolicLink，同样受权限限制；且对“目标是否为目录”不做自动推断——传入一个目录路径，它不会自动加SYMBOLIC_LINK_FLAG_DIRECTORY。
- Linux/macOS下该函数能正常工作，但Windows下仍需提前检查是否具备权限（可用
GetTokenInformation查SeCreateSymbolicLinkPrivilege） - 若目标路径是目录，必须显式调用
std::filesystem::create_directory_symlink，否则在Windows上静默失败或创建出损坏链接 - 某些旧版libstdc++（如GCC 8.3前）对Windows支持不全，
create_symlink可能抛std::filesystem::filesystem_error且.code().value()返回0——得靠.what()里是否含"privilege"来辅助判断
真正可靠的跨平台方案：降级+fallback+明确告知用户限制
不要指望一次调用通吃所有平台。生产环境更稳妥的做法是分层处理，而不是强求API语义一致。
立即学习“C++免费学习笔记（深入）”；
- 优先尝试
std::filesystem::create_symlink，捕获异常后检查错误码是否为operation_not_supported或权限类错误 - Windows上失败后，可fallback到
mklink /D（目录）或mklink（文件）命令，通过std::system调用，但需确保cmd.exe可用且路径不含空格/特殊字符（建议用GetShortPathName转短路径） - Linux/macOS上若
symlink失败且errno == EPERM，说明挂载点禁用了符号链接（如mount -o nosymfollow），此时只能报错退出，无法绕过
跨平台符号链接最麻烦的从来不是API调用，而是用户对“链接是否生效”的预期——比如在Windows资源管理器里双击一个符号链接，它可能直接打开目标，也可能提示“找不到项目”，取决于Explorer是否启用了“解析符号链接”策略。这点没法靠代码控制，只能文档里写清楚。
