std::filesystem::canonical抛出filesystem_error是因为它要求路径真实存在并可访问，而非仅字符串规范化；若路径可能不存在，应改用std::filesystem::absolute或手动normalize。

std::filesystem::canonical 为什么有时抛出 filesystem_error

调用 std::filesystem::canonical 获取绝对路径时，最常遇到的是 std::filesystem::filesystem_error，错误信息类似 "No such file or directory"。它不是“转换失败”，而是明确拒绝处理不存在的路径——哪怕只是中间某一级目录不存在，或目标是悬空符号链接。

这和很多人直觉相反：以为“规范化”就是拼出一个看起来合理的绝对路径。其实它本质是“解析真实存在路径的规范形式”，必须能真正访问到文件系统节点。

• 若只需拼接当前工作目录 + 相对路径，用 std::filesystem::absolute
• 若路径可能不存在但你仍想得到“理论上的绝对路径”，先用 std::filesystem::absolute，再手动 normalize 斜杠（见下一条）
• Windows 下注意驱动器号大小写不敏感，但 canonical 返回的路径会按实际卷标大小写呈现

std::filesystem::absolute 能否替代 canonical 处理不存在路径

std::filesystem::absolute 是安全兜底方案：它只做“基于当前工作目录的拼接 + 基础规整（如去掉 .、折叠 ..）”，不要求路径存在。

但它不解决所有问题——比如 /a/b/../c 会被转成 /a/c，但 /a/b/../../c 若 /a/b 不存在，absolute 仍会保留 ../c 段落，不会向上穿透到根目录外。

立即学习“C++免费学习笔记（深入）”；

C++14

C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。

下载

• 它默认以 std::filesystem::current_path() 为基准，可传入第二个参数指定 base path
• 结果中斜杠风格依赖平台：Windows 返回 \，Linux/macOS 返回 /；如需统一，得自己替换
• 不解析符号链接，也不检查权限，纯字符串逻辑+路径语义规整

手动 normalize 路径字符串的边界情况

当连 std::filesystem::absolute 都不能用（比如编译器不支持 C++17 filesystem），就得手写规整逻辑。核心是模拟“压栈式路径解析”：

把路径按 / 或 \ 切分，逐段处理：. 跳过，.. 弹出上一段，其余直接入栈。最后拼起来。

• 开头是否为根（/ 或 C:\）决定是否清空初始栈——否则相对路径会错误地挂到当前目录下
• Windows 驱动器前缀如 C: 必须整体视为一个段，不能拆成 C 和 :
• 结尾的 / 是否保留？取决于用途：URL 路由通常保留，文件操作一般可裁掉
• 多斜杠（//）和混合斜杠（/\）需提前统一，否则切分逻辑易错

跨平台路径拼接该用 / 还是 std::filesystem::path::operator/

别手拼字符串。用 std::filesystem::path 的 / 重载，它自动处理分隔符：

std::filesystem::path p = "/home";
p /= "user";
p /= ".config";
// Linux: /home/user/.config，Windows: \home\user\.config

硬写 "/" + a + "/" + b 看似简单，但会在 Windows 上生成非法路径（C:\foo/bar 虽然多数 API 能容忍，但 CreateFileW 某些模式下会失败）。

• std::filesystem::path 构造时接受任意分隔符，内部归一化；输出时按平台习惯返回
• 拼接时若某段含非法字符（如 Windows 的 <>:"/\|?*），path 不报错，但后续 create_directory 会失败——规整不等于校验
• 避免隐式转换：不要用 std::string 直接参与 path 运算，显式构造更安全

路径规整最麻烦的从来不是算法本身，而是得时刻分清：你在解决“路径存在性问题”还是“字符串格式问题”。前者靠 canonical，后者靠 absolute 或手写逻辑——混用就会在某个深夜收到用户发来的截图：“这个路径明明显示是绝对的，为啥打开失败？”