Windows用GetVolumePathName获取卷根路径并与标准化后路径比较来判断是否为驱动器根目录；Linux/macOS则通过lexically_normal()归一化后与"/"比较。
Windows下用GetVolumePathName判断是否为驱动器根目录
在Windows上，“根目录”通常指C:这类驱动器根，而非文件系统全局根（不存在）。直接比较路径字符串容易出错——比如"c:"、"C:/"、"C:\\\"都合法且等价。推荐用系统API做标准化判断：GetVolumePathName能把任意路径映射到其所在卷的根路径，再与原路径标准化后比对。
- 调用
GetVolumePathName(path.c_str(), volRoot, sizeof(volRoot))，成功则volRoot形如"C:\" - 用
std::filesystem::canonical(path)或PathCanonicalize规范化输入路径（注意：canonical可能抛异常，需捕获） - 比较规范化后的路径是否等于
volRoot；若相等，说明该路径就是这个卷的根目录 - 注意：传入路径必须存在，否则
GetVolumePathName失败；若不确定存在，先用std::filesystem::exists检查
Linux/macOS下检查std::filesystem::path是否为/
Unix-like系统只有一个真正的根目录：/。判断逻辑简单直接，但陷阱在于路径标准化和空路径处理。
-
std::filesystem::path p{"/"}和std::filesystem::path p{"/."}是不同对象，但p.lexically_normal()后都变成"/" - 安全做法：先
p = p.lexically_normal()，再判断p == std::filesystem::path("/") - 避免直接用
p.string() == "/"——因为"/foo/.."未归一化时字符串不是"/"，但语义上是根 - 注意：
std::filesystem::path("")是空路径，不等于"/"；std::filesystem::path("//")在大多数实现中也等价于"/"，但依赖POSIX行为，建议仍走lexically_normal()
跨平台统一判断的边界情况
没有“完全跨平台”的根目录定义——Windows每个驱动器有独立根，Unix只有一个全局根。强行统一会掩盖语义差异。
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- 若业务逻辑需要“当前路径所在卷/文件系统的最顶层”，Windows用
GetVolumePathName，Linux/macOS用std::filesystem::path("/") - 不要试图把
C:和/当作同一概念处理；它们层级结构不同，权限模型也不同 - 路径中含符号链接时，
lexically_normal()只做字面归一化，canonical()会解析链接——判断是否为根时，通常应使用lexically_normal()，除非明确需要解析链接后的实际位置 - 用户传入
"\servershare"（网络路径）时，GetVolumePathName可能失败，需单独处理；这类路径在Windows中无“根目录”概念
常见错误：用字符串匹配硬编码判断
写if (path == "C:\" || path == "/")看似简单，实则脆弱。
立即学习“C++免费学习笔记（深入）”；
- 大小写：Windows路径
"c:"合法，但字符串比较会失败 - 斜杠方向：
"C:/、"C:\\\"、"C:"（无尾随斜杠）都是有效驱动器根表示 - 冗余分隔符：
"//"、"///"在Unix下仍为根，但字符串匹配漏掉 - 宽字符/UTF-8混用：
std::wstring路径和std::string路径不能直接比，且BOM、代理对等问题会让字符串比较失效
真正可靠的判断永远依赖平台API或标准库路径操作函数，而不是手写字符串规则。最易被忽略的是：路径存在性验证和符号链接处理时机——这两步漏掉，canonical()可能抛异常，或返回意外结果。
