最安全的路径拼接方式是使用C++17的std::filesystem::path，它自动处理跨平台分隔符、冗余斜杠和相对路径（如..），应使用/运算符而非+或+=，输入需确保UTF-8编码，Windows下优先用.generic_string()避免乱码。
用 std::filesystem::path 拼接最安全，C++17 起原生支持
别手动拼 "a/" + b + "/c"，跨平台路径分隔符（/ vs \）、冗余斜杠、相对路径解析全会出问题。C++17 的 std::filesystem::path 内置规则：自动标准化分隔符、处理 .. 和 .、忽略空段。
实操建议：
- 构造
std::filesystem::path时传入任意字符串（含混合斜杠），它会归一化； - 用
/运算符拼接（不是+），例如：p1 / "subdir" / p2； - 最终用
.string()或.generic_string()取出结果（前者返回本地编码，后者强制 UTF-8 兼容格式）； - 注意：Windows 下
.string()返回宽字符转码后的本地 ANSI/GBK 字符串，若需稳定 UTF-8，优先用.generic_string()。
Windows 下用 std::filesystem::path 仍可能遇到中文路径乱码
根本原因不是拼接逻辑，而是源字符串编码。如果原始路径字符串是 GBK 编码的窄字符（如从旧 WinAPI 或控制台读入），直接构造 std::filesystem::path 会被当 UTF-8 解析，导致乱码。
解决路径：
立即学习“C++免费学习笔记（深入）”；
- 确保输入字符串是 UTF-8 编码（推荐：所有路径统一用 UTF-8 字符串）；
- 若必须处理 GBK 路径，先用
MultiByteToWideChar(CP_ACP, ...)转为std::wstring，再用std::filesystem::path构造函数重载（接受const std::wstring&）； - 编译时加
/utf-8（MSVC）或-finput-charset=utf-8（GCC/Clang），避免源文件字符串字面量被误判编码。
不支持 C++17 怎么办？慎用第三方或自制工具类
Boost.FileSystem 是最接近的替代，但引入依赖大、编译慢；自制字符串拼接函数极易漏掉边界情况（比如 "C:" 后是否加 \、UNC 路径前缀 \server\share 的处理）。
临时方案建议：
- 只做简单拼接且确定运行环境（如纯 Linux），可用
std::string手动拼/，但必须提前清理两端斜杠（std::filesystem::path("a").append("b").string()的等效逻辑）； - 若需兼容 Windows，至少用
std::filesystem::path的子集模拟：检测系统用#ifdef _WIN32切换分隔符，并手动调用std::regex_replace清理重复斜杠和./； - 绝对不要信任
strcat或snprintf拼路径——它们不理解路径语义，"a/b/../c"不会简化成"a/c"。
std::filesystem::path 的 / 和 += 行为有区别
/ 是组合（composition），语义是“在父路径下找子项”；+= 是追加（appending），把右边当纯字符串贴到末尾，不触发路径解析。
举例：
std::filesystem::path p = "a/b"; p /= ".."; // p 变成 "a"（正确解析上一级） p += ".."; // p 变成 "a/.."（字面拼接，未简化）
常见错误：误用 += 替代 /，尤其在循环拼接多个段时，结果路径无法被 exists() 或 is_directory() 正确识别。
记住：只要拼的是路径段（目录名、文件名、变量路径），一律用 /；只有明确要字面追加后缀（如 ".tmp"）才考虑 +=。
路径拼接真正的难点不在语法，而在编码一致性与上下文语义——同一个字符串，在命令行参数、配置文件、GUI 输入框里来源不同，编码就可能不同。别假设“用户给的路径一定合法”，先做 std::filesystem::weakly_canonical() 或至少 std::filesystem::canonical(p, base) 校验，比事后报 std::filesystem::filesystem_error 更省事。
