std::filesystem::path::root_name() 在 Windows 上仅对以盘符开头的绝对路径（如"C: oo"）返回驱动器号加冒号（如"C:"），对相对路径、UNC路径或类Unix绝对路径均返回空字符串；它不是通用盘符提取工具，需配合has_root_name()和is_absolute()判断，并限定Windows平台使用。
std::filesystem::path::root_name() 在 Windows 上返回什么
它返回的是驱动器号加冒号，比如 C:、D:，但**仅当路径是绝对路径且以盘符开头时才有效**。相对路径、UNC 路径（\servershare）、或带斜杠前缀的路径（如 /home）都会让 root_name() 返回空字符串。
- 正确示例：
std::filesystem::path{"C:\foo\bar"}.root_name()→"C:" - 错误示例：
std::filesystem::path{"./data.txt"}.root_name()→ 空"" - UNC 路径：
std::filesystem::path{"\\server\share\file"}.root_name()→ 空""（它走的是root_directory()+relative_path()）
为什么直接调用 root_name() 常常拿不到盘符
因为 root_name() 不是“提取盘符”的通用工具，而是文件系统路径解析的一部分——它只捕获路径开头的“根名”，而这个概念在不同平台语义不同：Windows 是盘符，Linux/macOS 是空（/ 是 root_directory()）。很多开发者误以为它等价于“取盘符函数”，结果在构造路径、拼接、或处理用户输入时出错。
- 路径未标准化：含
..或.的路径可能被解析为相对路径，导致root_name()失效 - 路径来自用户输入或配置，没做
std::filesystem::absolute()或std::filesystem::canonical()处理 - 误把
root_name()和root_path()混用：root_path()=root_name()+root_directory()，才是完整根（如C:\）
安全提取 Windows 盘符的实操方式
别依赖 root_name() 单独工作。真要拿盘符，得结合路径类型判断和字符串检查，尤其面对不可信输入时。
- 先用
std::filesystem::path::has_root_name()判断是否存在有效根名 - 再用
std::filesystem::path::is_absolute()确保是绝对路径（Windows 下通常意味着有盘符或 UNC） - 若两者都为 true 且路径以字母+冒号开头（如
"C:"），可安全取.root_name().string() - 更健壮的做法：对 Windows 平台，直接用
_getdrive()（MSVC）或解析path.string()[0]+ 冒号（需确认长度 ≥ 2 且第二字符是':'）
// 示例：安全提取盘符字符（仅 Windows）
std::filesystem::path p = "C:\temp\log.txt";
if (p.has_root_name() && p.is_absolute()) {
std::string rn = p.root_name().string();
if (rn.length() == 2 && std::isalpha(rn[0]) && rn[1] == ':') {
char drive_letter = rn[0]; // 得到 'C'
}
}
跨平台代码里千万别硬写 root_name() 提盘符
这段逻辑在 Linux/macOS 下会静默失败——root_name() 永远为空，但编译不报错，运行时路径拼接突然变成相对路径，后续 exists() 或 create_directories() 全部错位。
立即学习“C++免费学习笔记（深入）”；
- 如果业务确实需要盘符（比如日志写入固定盘、磁盘空间检查），应显式限定 Windows 平台分支
- 用
#ifdef _WIN32包裹盘符相关逻辑，Linux 下走挂载点或/proc/mounts方案 - 避免把
root_name()结果直接用于路径拼接，例如p.root_name() / "tmp"在非 Windows 下等于"" / "tmp"→"tmp"，意外变相对路径
root_name() 只是解析器按标准切出来的片段，它不负责语义还原。真正难的不是怎么调用，而是怎么判断此刻这个路径值不值得信。 
