不能直接用/或拼接路径，因跨平台分隔符不同且API敏感；推荐用C++17 std::filesystem::path重载/运算符自动处理，避免宏拼接。
为什么不能直接用 / 或 \ 拼接路径
因为 Windows 用 \ 作路径分隔符，Linux/macOS 用 /，硬写会导致跨平台编译失败或运行时找不到文件。更隐蔽的问题是：某些 API（如 fopen）在 Windows 下其实也接受 /，但 CreateFileA 或 Qt 的 QDir 对分隔符敏感；而 C++20 std::filesystem::path 虽能自动归一化，但宏展开发生在预处理阶段，无法调用运行时逻辑。
推荐方案：用 std::filesystem::path 替代宏（C++17 起）
宏本质是文本替换，没法做平台判断或类型安全检查，强行写 #ifdef _WIN32 宏反而增加维护成本。现代做法是放弃“拼接宏”，改用标准库的类型安全路径操作：
#include <filesystem>
namespace fs = std::filesystem;
fs::path p = fs::path("data") / "config.json"; // 自动用当前平台分隔符
fs::path full = fs::current_path() / "cache" / "temp.bin";
-
/运算符已重载，语义清晰且跨平台可靠 - 构造时若传入含混合分隔符的字符串（如
"a/b\c"），std::filesystem::path会内部规范化 - 注意：MSVC 19.29+、GCC 10+、Clang 12+ 才完整支持；旧版本需开启
-lstdc++fs链接选项
如果必须用宏（如兼容 C++11 项目），该怎么写
仅当项目无法升级标准、且路径拼接集中在极少数地方时才考虑。核心原则：只做分隔符选择，不尝试拼完整路径字符串。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 定义分隔符宏：
#define PATH_SEP (defined(_WIN32) ? '\' : '/')❌ 错误 —— 预处理器不支持三目运算 - 正确写法：
#ifdef _WIN32<br> #define PATH_SEP '\'<br>#else<br> #define PATH_SEP '/'<br>#endif
- 拼接仍需靠函数：宏只能生成单个字符，路径组装必须交给
std::string或snprintf，例如：std::string join(const std::string& a, const std::string& b) { return a + PATH_SEP + b; } - 绝对不要写类似
#define PATH_JOIN(a,b) a "/" b—— 字符串字面量拼接在跨平台头文件中极易因换行/空格破坏
容易被忽略的边界情况
即使用了 std::filesystem::path，仍有几个点常被跳过：
立即学习“C++免费学习笔记（深入）”；
- 相对路径开头的
./或../在拼接时不会自动折叠，fs::path("a") / "../b"结果是"a/../b"，需显式调用.lexically_normal() - Windows 下驱动器号（
C:\）和 UNC 路径（\\server\share）的根处理逻辑特殊，fs::path("C:") / "file.txt"≠fs::path("C:\") / "file.txt" - 构建脚本（CMake）里硬编码路径分隔符比代码里更危险 ——
set(RES_PATH "img\icon.png")在 Linux 构建机上会失效，应统一用file(TO_CMAKE_PATH ...)
真正的兼容性不在怎么拼，而在谁负责归一化：交给 std::filesystem，别让宏越俎代庖。
