C++17 filesystem 路径操作：别再用字符串拼接了，你真的会用 path 吗？

刚写完一段代码，想把日志写进 ./logs/2024/06/ 目录——结果发现目录不存在，得一层层 mkdir；或者路径里混着正斜杠和反斜杠，Windows 上跑得好好的，Linux 一跑就 std::filesystem::create_directories 报错……这些不是玄学，是你还没真正把 std::filesystem::path 当成“路径对象”来用，而只是把它当成了带点语法糖的 std::string。

C++17 引入的 <filesystem> 不是给路径加个 .string() 就完事的。它是一套有语义、可组合、跨平台感知路径结构的工具。用对了，路径操作从“手动排雷”变成“自然推演”。

路径不是字符串，是分段的“地址簿”

std::filesystem::path p = "/home/user/docs/report.txt";
这行代码创建的不是一个字符串容器，而是一个按分隔符自动切分并缓存结构的对象。你可以立刻问它：

• p.parent_path() → /home/user/docs（不是靠 rfind('/') 手撕）
• p.filename() → report.txt
• p.stem() → report（不含扩展名）
• p.extension() → .txt

更关键的是：这些操作不依赖当前系统分隔符。在 Windows 上写 path p = "C:\\data\\input.csv";，调用 p.parent_path() 返回的仍是逻辑上的父路径，不是 "C:\\data" 这个字符串——而是 path 对象，后续还能继续 .append("backup")，自动适配 \ 或 /。

别再用 + 拼路径了。p / "backup" / "v2" 是推荐写法，斜杠 / 是重载的路径组合运算符，语义清晰，且能正确处理边界情况（比如左边以 / 结尾、右边以 / 开头，不会生成 //）。

创建目录？别只盯着 create_directories

很多人卡在 create_directories("a/b/c") 失败，查半天发现是权限问题或磁盘满了——但更常见的原因是：路径里混了相对路径和绝对路径，或 . .. 没被规范化。

path p = "../cache/../logs/./2024";
直接传给 create_directories(p)？可能失败，也可能创建出意料之外的层级。
正确做法是先归一化：p = p.lexically_normal();
它会把 .. 和 . 消解掉，得到 logs/2024（如果是相对路径）或 /full/path/logs/2024（如果已转为绝对路径）。

顺手加一句：创建前最好先检查是否存在且是目录：

if (!exists(p) || !is_directory(p)) {
    create_directories(p);
}

exists() 查存在性，is_directory() 确保不是同名文件——这两步漏掉一个，后续 open() 就可能报 Is a directory 错误。

遍历目录？别自己递归写栈

for (const auto& entry : std::filesystem::directory_iterator("/src")) { ... }
这只是浅层遍历。真要找所有 .cpp 文件？别手写递归了。

用 recursive_directory_iterator：

for (const auto& entry : std::filesystem::recursive_directory_iterator("/src")) {
    if (entry.is_regular_file() && entry.path().extension() == ".cpp") {
        std::cout << entry.path().lexically_relative("/src") << "\n";
    }
}

注意 lexically_relative() —— 它能把绝对路径 /src/core/main.cpp 转成相对形式 core/main.cpp，方便日志输出或配置记录，不用再手动 substr()。

还有个小技巧：迭代器默认跳过符号链接（symlink）。如果需要遍历符号链接本身（而非目标），加个 directory_options::follow_directory_symlink 参数即可。

跨平台路径处理，核心就一条：用 u8path 构造

中文路径在 Windows 上常见，Linux 下也越来越多。直接 path p("测试/文件.txt") 在某些编译器+locale 下会出问题。

安全写法是：

auto p = std::filesystem::u8path(u8"测试/文件.txt");

u8path 明确告诉标准库：这是 UTF-8 编码的字符串。Windows API 内部会转为宽字符，Linux 下原样传递——避免乱码、避免 filesystem_error 报 “Invalid argument” 却找不到原因。

顺便提醒：path::string() 返回 std::string（UTF-8），path::wstring() 返回 std::wstring（Windows 下常用）。日常调试打印，优先用 path::string()，兼容性更好。

最后一个容易被忽略的习惯：路径操作尽量延迟求值

别一拿到字符串就急着 path p(str)；也别每次都要 p.string()。path 对象本身支持比较、拼接、查询，很多操作内部是惰性的（比如 parent_path() 只是调整内部索引，不涉及字符串拷贝）。频繁调用 .string() 反而增加开销，还可能引入编码转换隐患。

真正需要字符串的场景，其实就两类：

• 传给 C 风格 API（如 fopen(p.string().c_str(), "r")）
• 日志输出或用户提示（这时记得用 p.string()，别用 p.c_str()——后者类型不安全）

其余时候，让 path 对象一直“活”着。它比你想的更轻量，也更可靠。

写完这段代码，我删掉了三个自定义的 join_path 函数、两个手工写的路径解析逻辑，以及一行注释：“TODO: 修复 Windows 路径分隔符”。std::filesystem::path 不是银弹，但它把路径这件事，从“字符串工程”拉回了“领域建模”——路径本该有结构、有关系、有行为。你只需要尊重它的设计意图，它就会安静、稳定、跨平台地替你扛下所有琐碎。