std::filesystem::is_symlink是C++17起判断软链接最可靠跨平台方式，能正确处理悬空链接，但需前置exists或status_known检查以防异常。
用 std::filesystem::is_symlink 判断软链接最可靠
标准 C++17 起，std::filesystem::is_symlink 是唯一推荐的跨平台方式。它不依赖系统调用封装细节，能正确处理符号链接不存在但路径合法的情况（比如悬空链接），也避开 lstat 手动调用时的 ENOENT / ENOTDIR 等误判。
常见错误是直接传入未检查的字符串路径，导致抛出 std::filesystem::filesystem_error 异常：
try {
bool is_link = std::filesystem::is_symlink("/path/to/file");
} catch (const std::filesystem::filesystem_error& e) {
// e.what() 可能是 "No such file or directory"
// 这不代表不是软链接，只代表路径不可访问
}
- 务必先用
std::filesystem::exists或std::filesystem::status_known做前置判断，否则异常会中断逻辑 - 不要对空字符串、相对路径如
".."或含\0的字符串调用，行为未定义 - Windows 上需启用 NTFS 符号链接支持（管理员权限创建，且目标路径存在时更稳定）
_is_symlink 不是标准函数，别在跨平台代码里用
这个函数名是某些旧版 MSVC CRT 的内部扩展，Linux/macOS 根本没有，Clang/GCC 编译直接报 undefined reference。网上搜到的示例多是混用了 Windows API（GetFileAttributesW）或 POSIX（lstat）再包装，但名字仿造成 _is_symlink 容易误导。
- Windows 下可用
GetFileAttributesW(path) & FILE_ATTRIBUTE_REPARSE_POINT，但仅当是 NTFS 符号链接或目录交接点才成立；快捷方式（.lnk）不满足 - Linux/macOS 必须用
lstat检查st_mode & S_IFLNK，不能用stat（会穿透链接） - 若强行封装成统一函数名，必须做编译期条件分支（
#ifdef _WIN32），且行为语义无法完全对齐
悬空软链接怎么判断？is_symlink 本身就能处理
悬空链接（dangling symlink）指目标路径不存在的软链接。很多人以为必须先 stat 目标才能确认，其实没必要——std::filesystem::is_symlink 对悬空链接返回 true，只要该路径本身是一个符号链接类型的文件系统项。
立即学习“C++免费学习笔记（深入）”；
- 示例：
ln -s /nonexistent target→std::filesystem::is_symlink("target")返回true - 但
std::filesystem::exists("target")返回false，因为目标不可达 - 若需要区分“是链接”和“能访问目标”，得组合调用：
is_symlink && exists - 注意：
std::filesystem::read_symlink在悬空时抛异常，不是返回空字符串
性能和线程安全要注意什么？
每次调用 std::filesystem::is_symlink 都触发一次系统调用（lstat 或等价 API），频繁检测同一路径会成为瓶颈。它本身是线程安全的，但不保证底层文件系统状态不变。
- 避免在循环里反复检测同一个路径，缓存结果比重复调用更高效
- 如果路径来自用户输入或网络，注意路径遍历风险（如
../../../etc/passwd），应先规范化：std::filesystem::weakly_canonical或白名单校验 - Android NDK r21+、部分嵌入式 libc++ 实现可能未完整支持
std::filesystem，需确认__cpp_lib_filesystem宏值
真正容易被忽略的是：符号链接的“类型”和“可访问性”是两个独立维度，硬凑成一个布尔判断反而掩盖问题。该查什么，就调用对应的函数，别指望一个接口包打天下。
