c++oding="utf-8" ?>
绝大多数场景该用 std::filesystem::weakly_canonical，因为它只做路径语法归一化且不检查文件存在性；canonical 要求路径真实存在，易因缺失目录而抛异常，性能也更差。
用 std::filesystem::canonical 还是 std::filesystem::weakly_canonical？
直接回答：绝大多数场景该用 std::filesystem::weakly_canonical，而不是 std::filesystem::canonical。前者只处理路径语法（如 .、..、重复斜杠），不检查文件是否存在；后者要求所有中间目录和最终路径都真实存在，否则抛出 std::filesystem::filesystem_error。
常见错误现象：canonical("a/../b") 在当前目录下没有 a 目录时直接崩溃，而你只是想规整字符串形式的路径。
- 使用场景：配置文件里读到的相对路径、URL 解析后的路径片段、日志中拼接的临时路径
- 参数差异：
weakly_canonical接受不存在的路径，返回“尽可能规整”的结果；canonical是“绝对且真实”的路径，代价高、失败率高 - 性能影响：前者纯字符串/路径运算，毫秒级；后者可能触发多次系统调用（stat），尤其在 NFS 或容器挂载路径下明显卡顿
std::filesystem::path::lexically_normal 能不能替代？
能，但只解决一半问题——它只做词法归一化，不解析符号链接，也不转成绝对路径。
比如：path("foo/../bar").lexically_normal() 得到 "bar"（正确），但 path("../data/file.txt").lexically_normal() 仍是 "../data/file.txt"（没变），因为它不结合当前工作目录做推导。
- 适合场景：纯路径字符串清洗（如模板渲染、路径拼接前的预处理），不涉及运行时实际访问
- 容易踩的坑：误以为它等价于“规范化”，结果在跨目录操作时路径错位
- 兼容性注意：C++17 起可用，但某些旧版 libstdc++（如 GCC 8.2 前）对 Windows 驱动器前缀处理有 bug，建议升级或加测试
Windows 下路径分隔符和驱动器盘符怎么处理？
别手动替换 '' 或拼接 "C:" —— std::filesystem 内部已按平台自动适配，硬编码反而出问题。
典型错误：把 "C:/a/../b" 传给 weakly_canonical，却在 Windows 上得到 "C:\b"（正确），但若先用 replace_all 把 '/' 换成 '\'，再传入，反而可能破坏路径对象的解析逻辑。
- 正确做法：统一用正斜杠
'/'构造std::filesystem::path，它会自动转义和标准化 - 驱动器盘符：确保路径以
"C:"或"C:/"开头，单独"C:"是相对路径（指向当前 C 盘工作目录），"C:/"才是根目录 - 性能提示：频繁构造
path对象开销很小，别为省一次构造去拼 raw string
为什么规整后路径长度反而变长了？
因为 weakly_canonical 和 canonical 默认返回绝对路径，会补全当前工作目录前缀（如从 "./a/../b" 变成 "/home/user/b"）。
这不是 bug，是设计行为。如果你明确需要相对路径结果，得自己截断：
auto abs = std::filesystem::weakly_canonical("a/../b");
auto rel = std::filesystem::relative(abs, std::filesystem::current_path());
但要注意：relative 同样要求两个路径都存在（或至少父目录存在），否则抛异常。更稳妥的做法是：只在确认目标路径应相对于某基准时才用它，否则就接受绝对路径——多数 I/O API（如 open、fopen）根本不在乎路径是否“短”。
真正容易被忽略的是：路径规整不是万能消毒剂。它不校验权限、不检测循环软链、不处理空字符或控制符。如果输入来自不可信源（如 HTTP 参数），得额外做过滤和白名单校验。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
