根本原因是std::filesystem::status()默认不追踪符号链接目标，且权限不足时返回file_type::none；应优先用symlink_status()+status()组合、传error_code避免异常，并在Windows上补充Win32 API识别reparse_point。
为什么 status() 返回的 file_type 经常是 none 或 unknown
根本原因不是代码写错了，而是 std::filesystem::status() 默认只读取符号链接本身的元信息，不追踪目标。如果路径是软链接且没加 symlink_option::follow_directory_symlink（C++17）或没用 std::filesystem::symlink_status() 对比，就极大概率拿到 file_type::symlink 或 file_type::none —— 尤其在 Linux/macOS 上，普通用户对符号链接没有读权限时，status() 会直接失败并返回 file_type::none。
实操建议：
- 先用
exists(p)确认路径存在，再调用status(p)；否则未定义行为或抛异常 - 若需真实类型（比如想区分“这个 .so 文件到底是目录还是普通文件”），优先用
symlink_status(p)获取链接本身，再用status(p)获取目标类型（自动解引用） - Windows 下通常无此困扰，但跨平台代码必须统一处理：显式捕获
std::filesystem::filesystem_error，检查.code().value()是否为EPERM或EACCES
file_type 枚举值的真实含义和常见误判场景
std::filesystem::file_type 只有 5 个值：regular、directory、symlink、block、character、socket、unknown、none。注意：none 不代表“不是文件”，而是“无法获取类型”（如权限不足、路径不存在、NFS 挂载异常）；unknown 表示文件系统不支持该类型标识（如某些嵌入式 FAT32 驱动）。
容易踩的坑：
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 把
is_regular_file(status(p))和status(p).type() == file_type::regular当作等价——其实前者内部做了额外判断（例如过滤掉 socket、device），更安全 - 在容器或 chroot 环境中调用，
status()可能因挂载点隔离返回file_type::none，此时应 fallback 到file_size()+is_directory()组合推断 -
file_type::regular不代表可读：它只是文件系统标记，实际 open() 仍可能因权限失败
C++17 filesystem 中获取类型最稳的三步写法
别依赖单次 status() 调用。生产环境推荐分层判断：
std::filesystem::path p = "/etc/passwd";
std::error_code ec;
auto s = std::filesystem::status(p, ec); // 不抛异常，用 ec 检查
if (ec) {
// 处理错误：ec.value() == ENOENT → 不存在；EACCES → 权限不足
}
else if (s.type() == std::filesystem::file_type::regular) {
// 安全分支
}
else if (s.type() == std::filesystem::file_type::symlink) {
auto target_status = std::filesystem::status(p, ec); // 自动解引用
if (!ec && target_status.type() == std::filesystem::file_type::regular) {
// 真实类型是 regular
}
}
关键点：
- 永远传
std::error_code&参数，禁用异常路径（避免在 signal handler 或嵌入式中崩溃） - 对符号链接，
status(p)在 C++17 中默认 follow，但某些 libstdc++ 旧版本（如 GCC 8.3）有 bug，仍需手动canonical(p, ec)辅助验证 - 不要用
operator==直接比file_type和整数，枚举底层类型未指定，GCC/Clang 实现可能不同
Windows 上 file_type::reparse_point 怎么办？
C++17 标准库不暴露 reparse_point（如 NTFS 符号链接、卷挂载点、OneDrive 占位符文件），status() 对它们一律返回 file_type::regular 或 file_type::directory。这意味着你无法仅靠标准库区分 “真实文件” 和 “云同步占位符”。
务实方案：
- Windows 平台必须补充 Win32 API：
GetFileAttributesExW(p.c_str(), GetFileExInfoStandard, &data)，检查dwFileAttributes & FILE_ATTRIBUTE_REPARSE_POINT - 对于 OneDrive/SharePoint 文件，还需调用
GetStorageInformation()或解析FILE_ATTRIBUTE_OFFLINE - 跨平台程序可封装一层：
platform_file_type(p)，Linux/macOS 走status()，Windows 走 Win32，对外统一返回扩展枚举
标准库的 file_type 是个最小可用集，不是全量文件系统语义。真正做文件管理工具时，别把它当唯一依据。
