std::filesystem::canonical会递归解析符号链接并返回真实物理路径，但要求路径所有中间组件必须存在且可访问，否则抛出filesystem_error；它不是简单拼接，而是逐级展开symlink、处理..和.，结果必为绝对、无链接、无冗余的唯一路径。
canonical 会递归解析 symlink，不是简单拼接路径
很多人以为 std::filesystem::canonical 只是把相对路径转成绝对路径，其实它真正做的是「从给定路径出发，沿着所有 symlink 逐层展开，最终定位到一个真实存在的、不带符号链接的物理路径」。这意味着：如果中间任何一环不存在、权限不足或形成循环链接，调用就会抛出 std::filesystem::filesystem_error。
常见错误现象：canonical("foo/bar") 报错 “No such file or directory”，哪怕当前目录下确实有 foo/——因为 bar 本身可能不存在，或 foo 是个损坏的 symlink。
- 必须确保路径终点（或至少其父目录链）真实存在且可访问
- 工作目录会影响结果：
canonical("data.txt")依赖当前std::filesystem::current_path() - 不会自动创建缺失的中间目录；它只解析，不修正
正确调用 canonical 的三步准备
直接传入路径字符串大概率失败。稳妥做法是先确认基础条件：
- 用
std::filesystem::exists()检查目标路径是否可达（注意：对 dangling symlink 返回false） - 用
std::filesystem::is_symlink()和std::filesystem::read_symlink()手动验证 symlink 链是否断裂 - 显式指定 base path：传入第二个参数
std::filesystem::path作为解析起点，避免隐式依赖当前工作目录
示例：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
try {
auto abs = std::filesystem::canonical("config/../conf/app.yaml", "/etc/myapp");
// → /etc/myapp/conf/app.yaml（不是 /etc/conf/app.yaml！）
} catch (const std::filesystem::filesystem_error& e) {
// e.what() 包含具体失败原因，比如 "Too many levels of symbolic links"
}
canonical 与 absolute 的关键区别
std::filesystem::absolute() 只做字面拼接：把相对路径补上当前工作目录前缀，不检查文件是否存在，也不处理 symlink。而 canonical() 必须访问文件系统，代价更高，但结果更“真实”。
- 性能差异明显：在 NFS 或远程挂载点上调用
canonical可能卡顿数秒 - 跨平台行为一致，但 Windows 上对 junction point 和 mount point 的处理逻辑与 Unix symlink 不同，需实测
- 若只需标准化路径格式（如去掉
./、../），且确定路径存在，canonical是唯一选择；否则优先用absolute+lexically_normal()
容易被忽略的权限和挂载点问题
即使路径存在，canonical 仍可能失败——尤其是当某一级目录不可读（no permissions）或位于未挂载的子卷（例如 Linux 中某个 bind mount 尚未激活）时。错误信息里常出现 “Permission denied” 或 “Invalid argument”，但不会明确指出是哪一层出问题。
- Linux 下可通过
strace -e trace=stat,lstat,readlink观察canonical实际触发的系统调用 - macOS 上对 APFS snapshot 路径的支持有限，某些只读快照内调用会失败
- 容器环境中，宿主机 symlink 指向容器外路径时，
canonical会解析失败，而非静默截断
实际部署时，别假设 canonical 总能成功；捕获异常后，根据业务需要 fallback 到 absolute 或记录原始路径。
