最可靠的方式是用预定义宏\_WIN32和\_\_linux\_\_在编译期判断平台：\_WIN32在所有Windows编译器下均定义，\_\_linux\_\_为GCC/Clang在Linux下的标准宏；需显式覆盖macOS等平台并避免路径硬编码与头文件误包含。
用 _WIN32 和 __linux__ 判断 Windows/Linux 最可靠
直接看预定义宏，别碰 uname() 或运行时检测——编译期就能分清平台，且无额外依赖。_WIN32 在所有 Windows 编译器（MSVC、Clang、GCC）下都定义，包括 64 位；__linux__ 是 GCC/Clang 在 Linux 上的标准宏（注意双下划线，不是 linux 或 LINUX）。_WIN64 可用于进一步区分位数，但判断“是否 Windows”只需 _WIN32。
常见错误：
- 误用
WIN32（旧版 MSVC 才有，现代 Clang/GCC 不定义） - 误写
__linux（少一个下划线，不生效） - 把
_MSC_VER当操作系统宏（这只是编译器标识，Windows 下用 GCC 就没它）
#ifdef 嵌套写法要防漏判 macOS 或其他系统
如果只写 #ifdef _WIN32 / #elif __linux__，那 macOS、FreeBSD、嵌入式系统都会掉进 #else 分支，容易误以为是 Linux。实际项目中建议显式覆盖主流目标：
#ifdef _WIN32
// Windows 路径分隔符、API 调用等
#elif defined(__linux__)
// Linux 特有 syscalls、procfs 访问
#elif defined(__APPLE__)
// macOS：mach_absolute_time、CFBundle 等
#else
#error "Unsupported platform"
#endif
注意：__APPLE__ 必须和 __MACH__ 配合用才严谨，但绝大多数 Apple 官方工具链（Clang + Xcode）同时定义两者，单独用 __APPLE__ 已足够。
跨平台路径拼接别硬编码 '\\' 或 '/'，用宏抽象
文件路径逻辑最常因平台差异出错。不要在代码里写 "C:\\foo\\bar" 或 "./data/config.json" 这种固定分隔符——即使 Linux 下 '/' 也能被 Windows API 接受，但语义混乱且影响可读性。
推荐做法：
- 定义统一路径分隔符宏：
#define PATH_SEP (defined(_WIN32) ? '\\' : '/')（需在 constexpr 或字符串字面量外使用） - 更稳妥的是封装函数，如
std::string join_path(const std::string& a, const std::string& b)，内部根据_WIN32选分隔符 - 避免用
std::filesystem::path做条件编译依据——它本身跨平台，但底层行为仍依赖 OS，不该用来反推系统类型
第三方库头文件包含顺序受平台宏影响
比如 <windows.h> 只能在 Windows 下 include，且必须早于某些 POSIX 头（如 <sys/stat.h>），否则宏冲突。Linux 下若误 include <windows.h>，编译直接失败。
正确组织方式：
- 每个源文件顶部先做平台判断，再按需 include：
#ifdef _WIN32→#include <windows.h>→#include <winsock2.h>#elif defined(__linux__)→#include <sys/epoll.h>、<sys/sendfile.h>- 避免在头文件里无条件 include 平台专属头，防止被其他平台代码间接引入
宏判断看似简单，但一旦混入构建系统（如 CMake 的 target_compile_definitions）或被头文件传播，就容易出现“本该定义却未定义”或“重复定义冲突”。最稳的方式是：所有平台相关逻辑集中在少数几个 .cpp 文件里，用内联函数封装，头文件只暴露统一接口。
