应使用 std::filesystem::path 而非 + 或 strcat 拼接路径，因其自动处理跨平台分隔符、归一化及路径语义；C++17 起原生支持，推荐用 / 运算符拼接并全程保持 path 类型。
为什么不能直接用 + 或 strcat 拼路径
因为不同系统用的路径分隔符不一样：/ 在 Linux/macOS， 在 Windows。硬拼容易出错，比如 "C:\foo" + "/" + "bar" 会变成 C: oo/bar，Windows 下可能无法识别；而 "home/user" + "\" + "file" 在 Linux 下根本不是合法路径。更麻烦的是，多层 //、\、开头或结尾冗余分隔符，都会让 std::filesystem::exists() 返回 false 即使文件真实存在。
用 std::filesystem::path 是最稳妥的选择
C++17 引入的 std::filesystem 已原生支持跨平台路径操作，无需第三方库，且自动处理分隔符、归一化（如 "a//b/./c" → "a/b/c"）和相对路径解析。
实操建议：
-
std::filesystem::path重载了/运算符，不是+：写p / "subdir" / "file.txt"，不是p + "/subdir/file.txt" - 构造时传入字符串，会按当前平台规则解析；但推荐统一用
/作为输入分隔符（std::filesystem内部会自动转换） - 避免手动调用
.string()后再拼接——这会丢失路径语义，应全程保持path类型，只在最终需要 C 字符串或打印时转出
示例：
立即学习“C++免费学习笔记（深入）”；
#include <filesystem>
namespace fs = std::filesystem;
fs::path join(const fs::path& base, const fs::path& rel) {
return base / rel; // 自动处理分隔符和归一化
}
// 调用
auto p = join("C:\temp", "data/log.txt"); // Windows 下结果是 "C:\temp\data\log.txt"
auto q = join("/home/user", "config.json"); // Linux 下结果是 "/home/user/config.json"
需要兼容 C++14 或更低版本怎么办
没有 std::filesystem 时，别自己手写分隔符逻辑——容易漏掉边界情况（如盘符、UNC 路径、URL-like 字符串）。推荐轻量级替代方案：
- 用
boost::filesystem::path（与std::filesystem接口几乎一致，只需把命名空间换成boost::filesystem） - 若拒绝引入 Boost，可封装一个极简函数，只做安全拼接（不归一化、不解析）：
关键点：
- 检查
base是否为空或已以分隔符结尾，rel是否以分隔符开头，避免重复分隔符 - 用
fs::path::preferred_separator不可靠（C++14 没这东西），直接用'/'作为统一输入分隔符，运行时根据平台选'/'或'\' - Windows 下需额外判断
base是否为盘符路径（如"C:"），否则"C:" / "foo"可能变成"C:foo"（相对路径，非"C:\foo"）
容易被忽略的细节：路径所有权和编码
std::filesystem::path 内部存储的是 std::string 或 std::wstring，取决于编译器和平台默认行为。Windows 上 MSVC 默认用 wstring 存储，Linux/macOS 用 string。这意味着：
- 不要假设
.c_str()总是返回 UTF-8 —— Windows 上它可能是 UTF-16（const wchar_t*），直接传给 POSIX API 会崩溃 - 跨平台项目若需稳定 UTF-8 输出，应在最终调用前显式转码：
.u8string()（C++20）或用std::filesystem::path::string()+ 手动 UTF-8 转换（C++17） - 路径拼接本身不涉及编码转换，但后续打开文件、创建目录时，API 对编码敏感——比如
open()要求 UTF-8，CreateFileW()要求 UTF-16
真正难的从来不是拼字符串，而是确保拼出来的路径，在目标系统上能被正确解码、被系统 API 正确接收。
