平台条件编译需依赖系统预定义宏（如__linux__、_win32、__apple__），避免自定义错误；优先用#if defined()防拼写失误，头文件卫士应坚持#ifndef标准写法；平台差异应收敛至薄抽象层，而非源码中滥用#ifdef。
怎么用 #ifdef 和 #ifndef 做平台判断
条件编译不是“写一次、到处跑”的魔法，而是靠预处理器在编译前剔除不匹配的代码块。关键不是记语法，是搞清哪些宏系统真会定义、哪些得自己加。
常见错误：直接写 #ifdef WINDOWS —— Windows 系统默认不定义这个，VC++ 定义的是 _WIN32 或 _MSC_VER，MinGW 可能只定义 __MINGW32__；Linux 下通常有 __linux__（注意双下划线），macOS 是 __APPLE__ 加 __MACH__。
- 优先用公认宏：
#ifdef __linux__、#ifdef _WIN32、#ifdef __APPLE__ - 避免自定义宏污染：如果必须加自己的平台标记（比如
MY_PLATFORM_MOBILE），统一在构建系统（CMake/Makefile）里用-DMY_PLATFORM_MOBILE传入，别硬写在源码里 - 嵌套要克制：两层
#ifdef嵌套后，可读性断崖下跌，不如把平台差异逻辑抽成小函数，用inline或链接时决议
#if defined() 比 #ifdef 更安全吗
安全，但不是因为“更高级”，而是因为它允许组合判断，且不会因拼错宏名导致静默失效。
典型翻车现场：#ifdef _DEBUG_ 写成 #ifdef _DEBUG（少个下划线）—— 预处理器照常跳过整个块，编译通过，但调试逻辑彻底消失，运行时才暴露问题。
立即学习“C++免费学习笔记（深入）”；
- 用
#if defined(_DEBUG)能避免拼写盲区，而且支持逻辑运算：#if defined(_WIN32) && !defined(__MINGW32__) -
#ifdef仅适合单宏快速判断；一旦涉及版本号比较（如#if _MSC_VER >= 1920），必须用#if，因为#ifdef不解析数值 - 所有宏判断都发生在预处理阶段，对运行时性能零影响，但会影响目标文件大小——没被选中的代码块完全不进编译流程
为什么 #pragma once 不能替代头文件卫士
它能替代，但只在绝大多数现代编译器上成立；而 #ifndef + #define + #endif 是 C/C++ 标准保证的通用方案。
问题出在边缘场景：某些 IDE 的索引器、老旧的嵌入式工具链（比如早期 IAR）、或跨平台构建中混用不同编译器时，#pragma once 可能被忽略或行为不一致。
- 头文件卫士命名别偷懒：
#ifndef MYLIB_UTILS_H比#ifndef UTILS_H更安全，避免和第三方库撞名 - 不要在同一个项目里混用两种方式——虽然不报错，但会让新人困惑哪套是事实标准
-
#pragma once对符号链接（symlink）路径敏感，而传统卫士只看文件内容；如果你的构建流程涉及大量软链（比如 Bazel 或某些 CI 场景），这点可能引发重复定义
如何让条件编译逻辑不变成维护噩梦
最危险的不是语法写错，而是把业务逻辑和平台适配耦合在一起。比如在核心算法里塞满 #ifdef __ARM_ARCH_7A__，后面换架构就得全局 grep 改。
- 把平台差异收敛到薄层：定义统一接口（如
platform_sleep_ms(int ms)），各平台实现放在platform_win.cpp、platform_linux.cpp等独立文件里 - 用 CMake 控制源文件参与编译，比在源码里堆
#ifdef更干净：target_sources(mylib PRIVATE $:src/platform/linux/io.cpp>) - 条件编译块超过 10 行，立刻警觉——要么拆函数，要么提成独立模块；否则下次你或同事 debug 时，得手动模拟预处理器走一遍逻辑
真正的复杂点不在语法，而在“什么时候不该用条件编译”。比如浮点精度差异、线程调度行为、信号处理机制，这些没法靠 #ifdef 修复，得靠抽象层或运行时检测。别让预处理器替你承担本该由设计解决的问题。
