parent_path() 仅返回上一级路径，需手动循环调用并用 has_parent_path() 判断边界，循环后需额外 push 根路径以确保完整；切勿用 string() 截取替代，应依赖 path 的逻辑操作。
std::filesystem::path 的 parent_path() 怎么一层层向上取
直接调用 parent_path() 只返回上一级路径对象，不是所有父级；它不递归，也不包含根目录（比如 / 或 C:/），更不会自动停在驱动器或文件系统根。你得手动循环剥，而且要注意空路径和根路径的边界。
常见错误是写成 p = p.parent_path(); 却没检查 p != p.parent_path() —— 到根之后再调一次，parent_path() 会返回自身，死循环就来了。
- 用
while (p.has_parent_path())最安全，它在根路径（如/、C:/）时返回false - 每次迭代前先 push 当前
p到容器里，再更新p = p.parent_path()，否则会漏掉第一级父目录 - Windows 下注意：路径
C:\a\b的parent_path()是C:\a，不是\a；has_parent_path()对C:\返回false，对\server\share（UNC）也按规则判断
获取全部父路径（含根）的完整列表怎么写
标准库没现成函数，必须手写循环 + 判断是否已到根。关键是「是否把根加进去」——多数场景需要，但 parent_path() 自身不提供根，得单独补。
典型误操作：对 /home/user/file.txt 循环取 parent_path()，得到 /home/user → /home → /，但若起始路径是 /，循环根本不进，结果为空；而你其实想要一个只含 / 的列表。
立即学习“C++免费学习笔记（深入）”；
- 先用
std::vector<:filesystem::path></:filesystem::path>存结果 - 循环条件用
p.has_parent_path()，每次 push 当前p后再更新p - 循环结束后，再 push 一次
p（此时p就是根路径），确保根必在列表中 - 如果原始路径是相对路径（如
foo/bar.txt），parent_path()也会逐级返回foo→.，最后.的parent_path()是.自身，has_parent_path()返回false，所以不会无限循环，但结果不含文件系统根
为什么不能用 operator/ 配合 string 拼接来构造父路径
有人想用 p.string().substr(0, p.string().rfind('/')) 再 parse 成 path，这在跨平台和 Unicode 路径下极不可靠。Windows 用反斜杠，Linux/macOS 用正斜杠，而 std::filesystem::path 内部做了标准化处理，operator/ 和 parent_path() 都基于逻辑结构，不是字符串切片。
典型报错：std::filesystem::path: cannot convert empty string to path，就是字符串截断后为空还强转 path 导致的；还有路径含中文、emoji 或 字节时，string() 可能截断或乱码。
- 永远优先用
parent_path()，而不是string()+rfind() -
operator/是拼路径用的（如p / "sub"），不是拆路径的工具 - 如果真要从字符串生成 path，用
std::filesystem::path("...")构造，别自己解析分隔符
性能和异常注意事项
parent_path() 是纯内存操作，无 I/O、不访问磁盘，速度极快；但如果你在循环里反复调用 exists() 或 status() 判断每个父路径是否存在，就会变成 O(n) 系统调用，明显拖慢。
另一个坑：某些旧版 libstdc++（GCC \\server\share）支持不全，parent_path() 可能行为异常；Clang 12+、GCC 10+、MSVC 2019 16.8+ 基本没问题。
- 避免在循环体内做
std::filesystem::exists(p)，除非你明确需要验证每级存在性 - 编译时确认标准库版本，Windows 下优先用 MSVC 或较新 GCC
- 路径对象本身小（通常 24–48 字节），拷贝开销可忽略，不用刻意传引用
