c++oding="utf-8" ?>
应优先用std::filesystem::path::lexically_normal进行纯词法规整，它不访问文件系统、快且安全；若需部分解析不存在路径，改用weakly_canonical；canonical仅适用于需绝对真实路径的场景。
std::filesystem::canonical 会报 std::filesystem::filesystem_error 怎么办
它不是用来“规范化”当前路径的，而是试图解析成**绝对且真实存在**的路径。只要中间某级目录不存在、权限不足或是个悬空软链接，就直接抛异常。你只是想删掉 . 和 ..？别用它。
实操建议：
- 用
std::filesystem::weakly_canonical—— 它会尽可能向上折叠..，对不存在的路径也只截断到首个缺失部分，不炸 - 如果输入路径纯属字符串处理（比如日志拼接、配置路径预处理），且不依赖文件系统状态，直接走
std::filesystem::path::lexically_normal - 注意：
lexically_normal不检查文件是否存在，也不处理符号链接，但它快、稳、可预测
为什么 lexically_normal 有时没效果
它只做词法规整：合并连续斜杠、删 .、抵消相邻 .. 和普通段。但前提是路径是“相对干净”的字符串形式。常见失效场景：
- 路径末尾带斜杠（如
"a/../b/"）→lexically_normal保留末尾斜杠，结果变成"b/"，不是"b" - 含 Windows 风格反斜杠混用（
"a\..\b"）→ 在非 Windows 平台可能不识别为路径分隔符，规整失败 - 路径开头是
"./"但后续有..跨出根（如"./../b"）→ 它会保留"../b"，因为无法安全上溯到父目录外
解决办法：先调用 std::filesystem::path::remove_filename 或手动 trim 斜杠，再规整；跨平台时统一用 / 构造路径，或用 std::filesystem::path 构造器自动适配分隔符。
Windows 下盘符和 UNC 路径怎么安全规整
lexically_normal 对 "C:/a/../b" 没问题，但遇到 "C:../b"（相对当前驱动器工作目录）或 "//server/share/a/../b" 就容易出偏差——前者被当成本地相对路径，后者在某些 libstdc++ 版本中可能忽略开头双反斜杠。
- 显式转成绝对路径再规整：
std::filesystem::absolute(p).lexically_normal() - UNC 路径务必以
//或\\开头（取决于字符串字面量写法），避免被误判为普通相对路径 - MSVC 的 STL 实现对 UNC 支持更稳；GCC 12+ 之后的 libstdc++ 也已修复多数 UNC 边界 case，旧版本建议升级或手动拆解路径段处理
性能和线程安全要注意什么
lexically_normal 是纯内存操作，无系统调用，毫秒级；weakly_canonical 会 stat 每一级目录，慢一个数量级，且可能阻塞。
- 高频路径处理（如 HTTP 路由匹配、打包工具扫描）必须用
lexically_normal，别贪图“更准确”而引入 I/O - 所有
std::filesystem::path成员函数都是线程安全的（不修改共享 path 对象时），但如果你把同一个path实例传给多个线程并调用非 const 成员函数（如replace_filename），就得自己加锁 - 别在循环里反复构造
std::filesystem::path对象来规整——复用对象或用字符串视图预处理更省
真正麻烦的是混合了符号链接、挂载点、case-insensitive 文件系统（如 macOS APFS 默认）的场景，这时候 lexically_normal 和 weakly_canonical 都救不了你，得靠业务层约定路径输入规范。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
