std::filesystem::canonical要求路径必须存在，否则抛出异常；而lexically_normal仅做字符串规范化，不访问文件系统，安全高效，适用于路径预处理。
std::filesystem::canonical 为什么不能直接用
它确实能展开符号链接并转成绝对路径，但有个关键限制：canonical 要求路径最终指向的文件或目录**必须存在**。一旦遇到中间某级目录不存在、或目标被删除，就会抛出 std::filesystem::filesystem_error，无法用于预处理阶段的路径规整。
常见错误现象：canonical("a/../b") 在当前目录下没有 b 时直接崩溃；canonical("/tmp/link/to/nonexistent") 因符号链接终点失效而失败。
- 适用场景：路径已知有效，且你需要真实物理路径（比如日志归档、权限校验）
- 不适用场景：配置文件读取、命令行参数解析、构建系统路径预处理等“路径可能暂时不存在”的环节
- 替代思路：先做逻辑规范化（消除
.、..、重复斜杠），再按需调用canonical
手动规范化相对路径：用 std::filesystem::path::lexically_normal()
lexically_normal() 是纯字符串层面的规整，不访问文件系统，安全、快速、可预测。它会：
- 折叠连续斜杠为单斜杠（
/a//b/→/a/b/） - 移除末尾斜杠（
/a/b/→/a/b） - 消除
.段（/a/./b→/a/b） - 尽可能向上折叠
..（/a/b/../c→/a/c），但**不会越界**（/a/../b→/b，../b→../b）
示例：
立即学习“C++免费学习笔记（深入）”；
std::filesystem::path p = "../dir1/./dir2/../file.txt"; std::cout << p.lexically_normal() << "\n"; // 输出: ../dir1/file.txt
注意：它保留开头的 ..，这是正确行为——你不能假设当前工作目录就是根，盲目“提升”会破坏语义。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
如何安全地消除符号链接（仅当路径存在时）
符号链接只能在运行时解析，必须分两步走：先确保路径存在，再展开。推荐封装一个带 fallback 的函数：
- 先用
lexically_normal()做初步规整 - 再用
std::filesystem::exists()检查是否可达 - 若存在，用
canonical()获取物理路径；否则保留规整后的逻辑路径
示例逻辑：
std::filesystem::path normalize_path(const std::filesystem::path& p) {
auto norm = p.lexically_normal();
if (std::filesystem::exists(norm)) {
try {
return std::filesystem::canonical(norm);
} catch (const std::filesystem::filesystem_error&) {
// canonical 失败（如权限不足、循环链接），退回到 lexically_normal
return norm;
}
}
return norm; // 不存在，只做逻辑规整
}
这样既避免崩溃，又在可行时给出真实路径。不要试图用 read_symlink() 逐层手解——它不处理嵌套链接，且无法判断链接是否构成环。
Windows 下的路径分隔符与大小写问题
std::filesystem 默认接受正斜杠 / 和反斜杠 \，但 lexically_normal() 统一输出为 /（即使输入是 C:\a\b）。如果你需要保持平台原生风格，得手动替换：
- 用
.make_preferred()可转为\（Windows）或/（Linux/macOS） - 但注意：
make_preferred()不影响规范化逻辑，只改分隔符外观 - 大小写敏感性由 OS 决定：Linux 下
/A≠/a；Windows 下通常不区分，但 NTFS 卷可配置为区分——别依赖大小写相等判断路径
真正容易被忽略的是：跨平台代码里，lexically_normal() 对 C:/a/../b 和 c:/a/../b 视为不同路径（驱动器号大小写），而 Windows 文件系统可能认为它们相同。若需语义等价比较，应先转为小写驱动器 + lexically_normal()。
