std::filesystem::status无法可靠判断远程挂载点，因其统一返回directory；需结合系统api：linux用statfs()查挂载点f_type，windows用getdrivetype()和wnetgetconnection()。
用 std::filesystem::status 判断路径是否为远程挂载点不靠谱
直接调 std::filesystem::status(path) 看 file_type::directory 或 file_type::symlink 完全没用——本地目录、NFS 挂载点、Samba 共享映射盘符，在 C++17 标准里统统返回 file_type::directory。标准库压根不暴露“是否远程”的元信息，这是 POSIX 和 Windows 底层差异导致的，filesystem 模块有意做了抽象屏蔽。
实操建议：
- 别指望
std::filesystem单独完成这个判断 - 需要配合系统级 API：Linux 用
/proc/mounts或statfs()查f_type；Windows 用GetDriveType()+WNetGetConnection() - 跨平台封装时，必须做条件编译，没有银弹
Linux 下通过 statfs() 检查文件系统类型
statfs() 能拿到挂载点底层的 f_type，比如 NFS 是 0x6969，CIFS/Samba 是 0xff534d42（即 "SMB" 字符串小端），这些 magic number 在 <linux></linux> 里有定义（但注意不是所有发行版都默认导出）。
常见错误现象：直接 statfs(path.c_str(), &buf) 传入文件路径而非挂载点根路径，导致返回的是父挂载点的类型，误判。例如 /mnt/nfs/share/subdir 必须先用 std::filesystem::canonical() 找到实际挂载根（如 /mnt/nfs），再对它调 statfs。
实操建议：
- 先用
std::filesystem::weakly_canonical(path)归一化路径 - 逐级向上找挂载点：对每个父目录调
statfs，直到f_fsid改变或到达/ - 检查
buf.f_type是否匹配已知远程 FS 类型（0x6969,0xff534d42,0x517b（9P）等） - 不要依赖
buf.f_type的绝对值，有些内核版本用f_fsid.val[0]替代
Windows 下用 GetDriveType() + WNetGetConnection() 组合判断
GetDriveType(L"Z:") 对映射网络驱动器返回 DRIVE_REMOTE，但对 UNC 路径（如 \servershare）直接返回 DRIVE_NO_ROOT_DIR，这时候得先提取服务器/共享名，再调 WNetGetConnection() 看能否解析出本地驱动器映射关系。
使用场景：用户输入的是 Z:、Z:\data 或 \\nas\backup，三种写法处理逻辑不同。
实操建议：
- 用
std::filesystem::path::has_root_name()和has_root_path()区分 UNC / 驱动器路径 / 相对路径 - 对驱动器路径（如
Z:），直接GetDriveType()；返回DRIVE_REMOTE就是网络驱动器 - 对 UNC 路径，用
WNetGetConnection()尝试反查是否有本地映射；失败也不代表不是远程——可能直连未映射，此时需 fallback 到GetFileAttributesEx()查FILE_ATTRIBUTE_REPARSE_POINT并结合DeviceIoControl(...IOCTL_MOUNTDEV_QUERY_STABLE_GUID...)（极少见，一般可忽略） - 注意
WNetGetConnection()需要链接mpmig.lib或winmm.lib，且在无网络时可能阻塞数秒
为什么不能只靠 std::filesystem::is_symlink() 或 is_other()
有人试图用 is_symlink() 判断挂载点，因为某些 NAS 管理界面会建符号链接指向远程路径——但这完全是管理侧行为，和挂载机制无关。而 is_other() 在 Linux 下对所有挂载点都返回 false（因为它们仍是 directory），在 Windows 下对映射驱动器也返回 false（is_directory() 为 true）。
性能与兼容性影响：
- 反复调
statfs()或GetDriveType()开销很小，但频繁解析 UNC 路径或调WNetGetConnection()可能触发网络查询，务必加超时或缓存 - C++17
std::filesystem在 MinGW 上部分函数不可用（如canonical对 UNC 失败），需预检编译器和标准库实现 - 容器环境（Docker/K8s）中，挂载点可能是 bind mount 或 overlayfs，
f_type显示本地类型，但数据实际在远端存储——这种业务层语义，filesystem 层无法感知
真正难的不是查类型，而是定义清楚“什么是远程驱动器”：是物理位置？网络协议？还是用户权限模型？不同场景答案不同，代码得按需切分边界。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
