std::filesystem::status() 跟随符号链接返回目标状态，symlink_status() 返回链接自身状态；判断是否为符号链接必须用 is_symlink(symlink_status(p))，而非 status(p)。
symlink_status() 和 status() 的区别必须分清
用 std::filesystem::status() 查 symlink 会顺着链接走，返回目标文件的状态；而 std::filesystem::symlink_status() 才真正查链接本身——这是绝大多数人踩坑的起点。比如你删了一个 symlink 指向的文件，status() 会报 std::filesystem::file_status 为 no_exist，但 symlink_status() 仍能告诉你这确实是个有效的 symlink（哪怕目标已消失）。
常见错误现象：exists(p) 返回 false，却以为 symlink 不存在，其实只是目标没了；或者用 is_regular_file(p) 判断 symlink 本身，结果永远是 false（它当然不是 regular file）。
- 判断是否为符号链接：用
is_symlink(symlink_status(p))，不是is_symlink(status(p)) - 获取 symlink 目标路径：用
read_symlink(p)，它只接受真实存在的 symlink，否则抛std::filesystem::filesystem_error - 创建 symlink：用
create_symlink(target, link_path)，注意target是相对还是绝对路径——它会被原样写入链接内容，不自动解析
read_symlink() 报 “No such file or directory” 怎么办
这个错误不是说 read_symlink() 找不到链接文件，而是链接文件存在，但它的内容（即目标路径）指向了一个根本不存在的路径，且你传入的是相对路径 + 当前工作目录不匹配。C++17 的 read_symlink() 不做路径归一化，也不切换到链接所在目录再解析——它就按字面值读出来，然后由你决定怎么处理。
使用场景：部署脚本检查配置软链是否有效、构建系统验证工具链路径。
- 先确认链接文件存在且是 symlink：
is_symlink(symlink_status(p)) && exists(p) - 用
read_symlink(p)拿到原始字符串，再用weakly_canonical()尝试解析（但它对 dangling link 也会失败） - 更稳妥的做法：取链接父目录
p.parent_path()，拼上read_symlink(p)，再调exists()——这才是实际生效的路径解析逻辑
create_symlink() 在 Windows 上的行为差异
Windows 从 Win10 1703 起支持 symlink，但默认需要管理员权限或启用开发者模式；否则 create_symlink() 会抛 operation_not_supported 错误，而不是静默失败。而且 Windows 的 symlink 分 junction（仅限目录）、symbolic link（文件/目录均可）、hard link（仅文件），而 std::filesystem::create_symlink() 在 Windows 上实际调用的是 CreateSymbolicLinkW，不自动降级。
性能影响：Windows 上创建 symlink 比 Linux 开销大，且涉及 ACL 检查；若目标在另一卷，还可能触发跨卷限制。
- 跨平台代码里别假设
create_symlink()一定成功，要捕获std::filesystem::filesystem_error - Linux 下
target可以是相对路径，Windows 下建议用绝对路径，避免因 cmd.exe 当前目录和进程 cwd 不一致导致链接失效 - 测试时用
std::filesystem::is_symlink(symlink_status(p))而非std::filesystem::exists(p)来确认创建结果
循环 symlink 怎么检测和避免
std::filesystem 不提供内置循环检测，canonical() 遇到循环会抛 filesystem_error 带错误码 std::errc::too_many_symbolic_link_levels，但你不能靠它来预防——因为 canonical() 本身就会遍历，已经陷进去了。
容易被忽略的地方：很多工具用 recursive_directory_iterator 遍历时默认不跟随 symlink，但如果你手动调 canonical() 或 status() 处理每个 entry，就可能意外触发循环解析。
- 自己实现简单深度限制：记录已访问的
std::filesystem::path（注意用lexically_normal()归一化后再比较） - 不要对用户输入的任意路径无条件调
canonical()，尤其来自配置文件或 CLI 参数 - 用
symlink_status(p).type() == file_type::symlink先筛出链接，再决定是否读取和解析
循环 symlink 的真实麻烦不在创建时，而在后续所有隐式解析路径的操作里——一个没防住，整个遍历就卡死或崩溃。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
