std::filesystem::path 对多个斜杠不自动归一，C://foo 被误解析为 UNC 导致 parent_path() 等行为异常；应优先使用 lexically_normal() 归一化，它安全、标准、不访问文件系统，可将 C://temp///log.txt 变为 C:/temp/log.txt。
Windows 下 std::filesystem::path 对 // 和 /// 的实际行为
Windows 路径里出现多个连续斜杠（比如 C://foo///bar.txt）不会报错，但 std::filesystem::path 的解析结果可能和你预期不一致：它会把 // 当作网络路径前缀（UNC）的开始，后续内容会被当作主机名或共享名处理。例如 //host/share/file 是合法 UNC，但 C://foo 会被拆成根 C: + 空主机名 + foo，导致 .parent_path() 或 .filename() 返回意外结果。
- 用
std::filesystem::path("C://foo").string()得到的是"C://foo"，不是"C:/foo" -
std::filesystem::canonical()不会自动折叠多余斜杠，除非路径真实存在且能访问 - 跨平台代码中，
//在 Linux 下是普通分隔符冗余，但 Windows 下有语义歧义
用 std::filesystem::path::lexically_normal() 清理路径冗余
这是最直接、标准且无副作用的修复方式——它只做字符串归一化，不依赖文件系统状态，也不访问磁盘。
- 它会把
/a//b/./c/../d变成/a/b/d，同时把C:\\foo\\bar归一为C:/foo/bar - 注意：它不处理驱动器大小写（
c:/Foo不会转成C:/Foo），也不展开环境变量或波浪号（~） - 对不存在的路径也安全，适合在路径拼接后、打开前调用
示例：
std::filesystem::path p = "C://temp///log.txt"; p = p.lexically_normal(); // → "C:/temp/log.txt"
手动替换斜杠前必须先判断 OS 和路径类型
别直接用 std::string::replace() 全局替换 "//"，容易误伤 UNC 路径或 URL-like 字符串（比如 "https://example.com" 混在路径里）。
- 仅当确定是本地文件路径时才考虑字符串清洗；优先走
lexically_normal() - 若真要手动处理，先用
p.is_absolute()和p.has_root_name()排除 UNC（path.root_name() == "//"） - Windows 下统一用
'/'替换所有'\'再归一更稳妥，因为std::filesystem内部把'\'当等价分隔符，但混合使用（C:/a）可能干扰解析逻辑
第三方库或自定义函数的兼容性风险
有些项目用 boost::filesystem 或手写的路径工具函数处理双斜杠，但它们的行为未必和 C++17 std::filesystem 一致。
-
boost::filesystem::canonical()在路径不存在时抛boost::filesystem::filesystem_error，而标准库的lexically_normal()永不抛异常 - 自己写正则替换
"//+"容易漏掉开头的//（如//server/share）或末尾的斜杠，还可能破坏 URL 或注册表路径格式 - 如果项目已用
std::filesystem，没必要引入额外依赖来解决这个单一问题
路径归一这件事，关键不在“能不能修”，而在“什么时候修”——lexically_normal() 必须在路径构造完成、但尚未传给 open() 或 exists() 前调用；晚一步，就可能因 UNC 解析歧义触发权限错误或路径不存在的假阴性。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
