必须用 std::filesystem::canonical 实现真正规范化（解析所有.和..并映射到真实存在路径），但要求路径最终指向已存在的文件或目录，否则抛异常；若末尾组件可能不存在，则应使用 weakly_canonical。
用 std::filesystem::canonical 还是 std::filesystem::weakly_canonical？
直接说结论：想真正“规范化”（即解析所有 . 和 .. 并映射到真实存在路径），必须用 std::filesystem::canonical；但它的前提是路径最终指向一个**已存在的文件或目录**，否则抛出 std::filesystem::filesystem_error。如果路径末尾可能不存在（比如你正在构造一个待创建的文件路径），就得换 std::filesystem::weakly_canonical —— 它只解析前面存在的部分，对末尾不存在的组件保留原样。
常见错误现象：canonical("a/../b") 在当前目录下没有 a 目录时直接崩溃；有人误以为它和 Python 的 os.path.normpath 一样纯字符串处理，其实不是。
-
canonical：适合“确认路径有效性 + 规范化”，要求整条路径可遍历到底 -
weakly_canonical：适合“构造路径前清理中间冗余”，允许末尾组件不存在 - 两者都自动处理
.、..、重复斜杠（//），但不改变大小写或链接目标（那是absolute或read_symlink的事）
为什么 std::filesystem::absolute 不等于规范化？
absolute 只是把相对路径补上当前工作目录前缀，完全不碰 . 和 ..。比如当前在 /home/user，absolute("a/../b") 返回 /home/user/a/../b —— 看似“绝对”，但依然含冗余段，后续 open 或 stat 仍可能失败或绕远路。
使用场景：当你只需要确保路径有根（比如传给某些只接受绝对路径的 API），且明确知道路径中不含 .. 或能容忍未展开的 .. 时，才用 absolute。
-
absolute("x/./y") → "/current/x/./y"（.没被干掉） -
absolute("a/../b") → "/current/a/../b"（..也没被计算） - 性能影响：
absolute是纯字符串拼接，零系统调用；canonical需要逐级stat，慢且可能失败
跨平台路径分隔符怎么处理？
std::filesystem 内部统一用 / 处理，无论 Windows 还是 Linux。你传入 "a\b\..\c"（Windows 风格反斜杠）会被自动转换，canonical 后返回的 path 对象也默认用 / 分隔（除非显式调用 .make_preferred()）。
容易踩的坑：手动字符串替换 "" → "/" 是多余操作，反而可能破坏 UNC 路径（如 "\servershare"）；更危险的是，在 Windows 上把路径转成 C:.. 再喂给 canonical，而当前工作目录不在 C: 盘，会导致逻辑错乱。
- 始终用
std::filesystem::path构造路径，别用 raw string 拼接 - 读配置或用户输入的路径，直接塞进
path构造函数，它会自动 normalize 分隔符 - 输出给人看时，用
.string()（Linux/macOS）或.generic_string()（保持/）；需要 Windows 原生风格才用.make_preferred().string()
实际代码里怎么安全封装一个“软规范化”函数？
多数情况你既不想让 canonical 因末尾不存在就炸，又希望尽可能展开已知存在的上级路径。这时候得自己兜底：先试 weakly_canonical，再对结果中剩余的 .. 做有限解析（比如只处理末尾连续的 ..）。
示例逻辑：
std::filesystem::path normalize_path(const std::filesystem::path& p) {
try {
return std::filesystem::canonical(p);
} catch (const std::filesystem::filesystem_error&) {
// fallback: weakly_canonical + 手动 pop 末尾 ..（仅当父目录存在）
auto weak = std::filesystem::weakly_canonical(p.parent_path());
return weak / p.filename();
}
}
注意点：这个函数不解决符号链接循环、权限不足等深层问题；weakly_canonical 对 .. 的处理是“尽力而为”，比如 /a/b/../../c 中若 /a 存在但 /a/b 不存在，它只会解析到 /a，后面 ../../c 全部保留 —— 这就是为什么不能无脑信返回值是否“干净”。
最容易被忽略的地方：路径是否规范，最终取决于你下一步用它做什么。如果只是日志打印，lexically_normal 就够了；如果要 fopen 或 create_directories，就必须确认磁盘上真实可达 —— 而这永远无法 100% 静态保证。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
