应使用 std::filesystem::path::preferred_separator 获取平台原生分隔符，而非硬编码 / 或 ；若受限于旧标准，则需谨慎宏定义并排除 Cygwin/MinGW 等边界情况。
为什么不能直接写 / 或 \？
因为硬编码分隔符在跨平台项目里会立刻翻车：Windows 用 \，Linux/macOS 用 /，而 C++ 标准库本身不提供统一的路径分隔符常量。有人试过用 #ifdef _WIN32 手动切换，但漏掉 Cygwin、MSYS2 或 WSL 的边界情况，就容易在构建时路径拼接失败——比如生成 C:path/to/file 却被当成 C:/path/to/file 解析出错。
真正可靠的做法是依赖运行时或编译时已知的系统行为，而不是靠人肉判断。
std::filesystem::path::preferred_separator 是最简解
C++17 起，std::filesystem 提供了现成的静态成员 preferred_separator，它返回当前平台原生首选分隔符（'\' 或 '/'），类型是 char，可直接用于字符串拼接或条件判断。
- 不需要宏定义，不污染全局命名空间
- 无需
#include <windows.h></windows.h>或 POSIX 头，纯标准库 - 值在编译期不可知，但运行时稳定可靠——只要
std::filesystem可用，它就可用 - 注意：某些旧版 libstdc++（如 GCC 8 前）可能未完全实现，建议 GCC 9+ / Clang 7+ / MSVC 2019+
示例：
立即学习“C++免费学习笔记（深入）”；
std::string join_path(const std::string& a, const std::string& b) {
return a + std::filesystem::path::preferred_separator + b;
}
// Windows 上返回 "C:\foo\bar"，Linux 上返回 "/foo/bar"
不想用 std::filesystem？手动宏定义要避开三个坑
如果项目卡在 C++11/14，或禁用 std::filesystem（比如嵌入式环境），才考虑宏。但常见错误包括：
- 只判
_WIN32，漏掉__CYGWIN__和__MINGW32__——它们虽跑在 Windows 上，但文件系统语义更接近 POSIX，用\反而引发open()失败 - 把分隔符定义成字符串字面量（如
"\"），导致拼接时多出转义问题；应定义为字符宏：#define PATH_SEP '/' - 在头文件里重复定义，没加
#ifndef守卫，引发 ODR 冲突
安全写法（推荐）：
#ifndef PATH_SEP # if defined(_WIN32) && !defined(__CYGWIN__) && !defined(__MINGW32__) # define PATH_SEP '\' # else # define PATH_SEP '/' # endif #endif
拼路径时，分隔符只是表象，真正要防的是双重分隔符
即使拿到正确的 PATH_SEP，手拼路径仍易出错：比如 a = "/home"，b = "user"，写成 a + PATH_SEP + b 得到 /home/user 没问题；但若 a = "/home/"（末尾已有分隔符），结果就是 /home//user ——多数系统能容忍，但某些容器镜像或沙箱环境会拒绝解析。
更鲁棒的做法是：用 std::filesystem::path 构造器自动归一化：
std::filesystem::path p(a); p /= b; // 自动跳过冗余分隔符，且适配平台 return p.string();
如果不用 std::filesystem，至少做一次 trim_end 清理右端分隔符再拼接。
跨平台路径处理最难的不是“怎么选分隔符”，而是“什么时候不该自己选”——比如日志路径配置项、用户输入的路径字符串、第三方库返回的路径，都该交由 std::filesystem::path 解析后再取 native()，而不是拿宏去硬套。
