推荐优先使用#ifndef而非#pragma once，因其符合c/c++标准、可移植性强且能可靠处理硬链接等边界情况；#pragma once虽快但非标准，仅宜作为辅助手段。

什么时候该用 #pragma once 而不是 #ifndef 宏卫士？

它能替代传统头文件保护，但不是万能的——只在编译器支持且路径唯一时才可靠。#pragma once 由编译器直接识别，不依赖宏名，写起来快、不易手误重复定义，但跨平台构建或符号链接/硬链接存在时可能失效。

• 适合内部项目、单一构建环境（如只用 MSVC 或 Clang）
• 不适合需要严格 POSIX 兼容或被 CMake + 多种编译器混合调用的公共库
• 若头文件通过不同路径被包含（比如 src/foo.h 和 build/include/foo.h 是同一文件的两个硬链接），#pragma once 可能失效，而 #ifndef 仍有效

#pragma once 放哪儿？位置有没有讲究？

必须放在头文件最开头，且前面不能有任何非注释内容（包括空行、BOM、空白符都不行）。一旦编译器看到它，就会标记该文件为“已包含”，后续再遇到相同物理文件就跳过。

• 正确：

  #pragma once
  #include <vector>
  class Widget { ... };</vector>

• 错误：

  // 空行
  #pragma once  // 编译器可能忽略它

• 错误：

  /* BOM 或 UTF-8 BOM 字节在文件开头 */
  #pragma once  // 某些旧版 GCC 可能无法识别

和 #ifndef 混用会怎样？

可以共存，但没必要，而且容易引发困惑。现代编译器（GCC ≥ 10、Clang、MSVC）对 #pragma once 的处理是“如果识别到，就跳过整个文件；否则退回到宏卫士逻辑”。但如果同时写了两套，维护者会不确定哪套起作用。

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

• 不要这样写：

  #pragma once
  #ifndef MY_HEADER_H
  #define MY_HEADER_H
  // ...
  #endif

• 选一个：要么纯 #pragma once（推荐日常开发），要么纯 #ifndef（推荐发布库）
• 某些静态分析工具（如 clang-tidy）会警告冗余的宏卫士，尤其当 #pragma once 已存在时

哪些编译器不支持 #pragma once？现在还用担心吗？

几乎不用了。GCC 自 3.4 起、Clang 从第一天起、MSVC 自 1990 年代就支持。真正要警惕的是极少数嵌入式工具链（比如某些基于旧版 SDCC 或 IAR 的定制环境），以及部分预处理器模拟器（如某些构建系统自带的 fake-cpp）。

• 检查方法：在头文件里写 #pragma once，然后故意重复包含两次，看是否报重定义错误——没报就是生效了
• 如果你的 CMakeLists.txt 里写了 set(CMAKE_CXX_STANDARD 17) 或更高，基本可默认支持
• 真正麻烦的不是不支持，而是某些 CI 环境用了太老的 MinGW-w64（GCC 4.8 之前），这时建议统一加宏卫士兜底

实际项目里，#pragma once 看似简单，但它的可靠性完全绑定在“文件路径唯一性”和“编译器行为一致性”上——这两点在大型 monorepo 或生成代码场景下最容易出岔子。

C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！