应使用/运算符拼接路径，而非硬编码/或\；std::filesystem::path会自动适配平台分隔符，手动拼接易导致跨平台解析错误，如Linux将"dir\sub/file.txt"视为字面量路径。
为什么不能直接用 "/" 或 "\" 拼接路径
硬拼斜杠在 Windows 上可能临时跑通，但会立刻在 macOS/Linux 下出错——比如 "dirsub/file.txt" 在 Linux 解析为当前目录下的 "dir\sub/file.txt"（反斜杠被当字面量），而 Windows 对正斜杠其实兼容，但反过来就不行。更麻烦的是，std::filesystem::path 构造时若传入含错误分隔符的字符串，后续 .string() 或 .generic_string() 行为可能因平台差异导致路径失效。
std::filesystem::path 的正确拼接姿势
别手写分隔符，让 std::filesystem::path 自己处理。它的 / 运算符重载专为此设计，会自动适配当前平台：
#include <filesystem> namespace fs = std::filesystem; fs::path base = "/home/user"; fs::path sub = "data"; fs::path file = "config.json"; fs::path full = base / sub / file; // 自动用 "/" 或 "\"，取决于平台 // 结果：Linux/macOS → "/home/user/data/config.json" // Windows → "C:\home\user\data\config.json"（若 base 是绝对路径）
- 始终用
/运算符，不是+=或+—— 后者会做字符串拼接，丢失路径语义 - 避免混合使用原始字符串和
path：比如base + "/data"是错的；应写成base / "data" - 如果某段路径来自用户输入或配置文件，先用
fs::path{str}构造再参与拼接，它会标准化分隔符
跨平台路径拼接时容易忽略的细节
看似简单，但几个点不注意就会在 CI 或另一台机器上失败：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
fs::path构造时若字符串以"./"开头，不同平台对相对路径解析一致，但若混用"..\sub"这种 Windows 风格写法，Linux 下fs::path仍能识别，但可读性和维护性差，建议统一用正斜杠或直接用fs::path{".."}拼接 - 调用
.string()前确认编码：Windows 默认返回窄字符串（ANSI/GBK），中文路径可能乱码；生产环境建议用.u8string()（C++17）或.wstring()+ 宽字符 API - 某些旧版 MinGW 或 Android NDK 可能未完全实现
std::filesystem，需检查编译器支持（GCC ≥ 8.0，Clang ≥ 9.0，MSVC ≥ 2017 Update 15.7）并链接-lstdc++fs（GCC）
需要兼容 C++14 或更老标准怎么办
如果无法升级到 C++17，别自己写分隔符逻辑。推荐轻量级替代方案：
立即学习“C++免费学习笔记（深入）”；
- 用
boost::filesystem::path（接口几乎一致，只需替换命名空间和头文件） - 极简场景下，可封装一个函数：
std::string join_path(const std::string& a, const std::string& b)，内部用std::string::find_last_of("\/")判断结尾是否已有分隔符，再补一个fs::path::preferred_separator（需手动定义宏判断平台）——但这种做法只适合原型验证，长期维护成本高 - 避免用
std::experimental::filesystem，它已被弃用且各编译器实现不一致
路径拼接本身不难，难的是让每一段输入都经过 fs::path 构造、每一步拼接都用 / 运算符、每次输出都选对编码接口——漏掉任何一环，跨平台就只剩“运气好”。
