应使用 std::filesystem::path::preferred_separator 获取运行时分隔符，Windows 返回 ''，Linux/macOS 返回 '/'；优先用 path 拼接路径，仅必要时读取该值。
Windows 和 Linux 下 PATH_SEPARATOR 并不存在
标准 C++ 没有定义 PATH_SEPARATOR 这样的宏。你搜到的很多代码里写的 #define PATH_SEPARATOR '/' 或 '\'，都是手动硬编码，不是系统自动提供的宏。C++ 标准库（包括 <filesystem>）刻意回避了“分隔符”这个概念——它用路径对象抽象掉底层差异，而不是暴露一个字符给你拼字符串。
用 std::filesystem::path::preferred_separator 获取运行时实际分隔符
这是唯一可靠、跨平台、且反映当前系统行为的方式。它返回一个 char（不是字符串），值取决于程序运行环境：Windows 返回 '\'，Linux/macOS 返回 '/'。注意：它不等于 std::filesystem::path::separator（后者是所有合法分隔符的集合，比如 Windows 也接受 '/'）。
常见错误现象：
– 直接用 #ifdef _WIN32 判断并写死 '\'，结果在 Cygwin/MSYS2 或 WSL 里跑崩
– 把 preferred_separator 当成字符串用，比如 std::string(1, path::preferred_separator) 写成 std::string(path::preferred_separator)（编译不过）
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 永远优先用
std::filesystem::path拼接路径，例如path{"a"} / "b" / "c"，完全不用管分隔符 - 仅当必须生成纯字符串（如日志打印、与旧 C API 交互）时，才读取
std::filesystem::path::preferred_separator - 示例：
std::filesystem::path p = "data"; p /= "config.txt"; std::cout << p.string() << " "; // 自动用对的分隔符 std::cout << std::filesystem::path::preferred_separator << " "; // 输出单个 char
如果非要用宏（比如预处理器阶段拼接头文件路径），只能自己判断
预处理器无法调用运行时函数，所以 std::filesystem::path::preferred_separator 在这里无效。此时只能靠编译器宏做粗略判断，但要注意这些宏反映的是**编译目标平台**，不是运行平台：
常见错误现象：
– 在 Windows 上用 MSVC 编译出 Linux 二进制（交叉编译），_WIN32 仍为真，导致分隔符错用
– 在 macOS 上用 Clang 编译，__linux__ 不定义，误判为 Windows
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 优先避免在宏里硬编码分隔符；改用构建系统（如 CMake）注入变量
- 若必须用宏，按标准可移植宏顺序判断：
#ifdef __linux__→#elif defined(__APPLE__) || defined(__FreeBSD__)→#else（默认当 Windows） - 不要依赖
_MSC_VER或__GNUC__—— 它们是编译器标识，和系统无关 - 示例：
#if defined(__linux__) || defined(__APPLE__) # define PATH_SEP '/' #else # define PATH_SEP '\' #endif
为什么 std::filesystem::path 是更安全的选择
直接操作分隔符字符串极易出错：多一个斜杠、混用正反斜杠、URL 和本地路径混淆、UNC 路径（\\server\share）被截断……而 std::filesystem::path 内部会规范化、去重、处理相对路径、兼容各种输入格式。
性能影响几乎为零：构造 path 对象开销极小，且现代实现通常惰性解析；比手撕字符串 + find_last_of + substr 更快更稳。
容易被忽略的一点：
– std::filesystem::path 构造函数接受 const char*，但不会验证路径是否合法；preferred_separator 只在构造后访问才有意义；
– 如果你用的是 C++17 之前的版本，<filesystem> 可能不可用，此时应升级工具链，而不是回退到宏拼接
