pragma once 有时不生效，因其非C++标准语法，而是编译器扩展，老旧或嵌入式编译器可能忽略；路径敏感（如软链接、多路径引用同一文件）也会导致失效。
为什么 #pragma once 有时不生效
它不是 C++ 标准语法，而是编译器扩展。主流编译器（GCC、Clang、MSVC）都支持，但某些嵌入式工具链或老版本编译器可能完全忽略它——这时预处理阶段不会做任何去重，#include 多次就展开多次。
常见错误现象：redefinition of 'class XXX' 或 multiple definition of 'XXX'，尤其在跨模块包含、头文件被间接包含多次时突然出现。
- 不要依赖
#pragma once单独解决所有重复包含问题 - 若项目需兼容极端旧环境（如某些 TI C++ 编译器），必须搭配传统
#ifndef宏卫士 - 路径敏感：不同路径指向同一物理文件（如软链接、符号链接、挂载点映射），
#pragma once可能判为不同文件，导致失效
#pragma once 和 #ifndef 宏卫士怎么选
两者目标一致，机制完全不同：#pragma once 由编译器在打开文件时判断是否已见过该路径；#ifndef 是预处理器基于宏名做文本级检查。
使用场景差异明显：
立即学习“C++免费学习笔记（深入）”；
- 开发效率优先、团队统一用现代编译器 → 直接用
#pragma once，简洁不易出错 - 发布 SDK 或开源库，需最大兼容性 → 必须用
#ifndef XXX_H+#define XXX_H+#endif - 头文件里定义了模板或内联函数，且被多个 TU 包含 → 两种方式都能防止多重定义，但宏卫士的宏名若冲突（比如两个头都叫
COMMON_H），反而引发新问题
示例对比：
#pragma once // ✅ 简洁，但非标准
#ifndef MATH_UTILS_H #define MATH_UTILS_H // ... 内容 #endif // MATH_UTILS_H // ✅ 兼容，但需人工维护宏名
哪些情况 #pragma once 会悄悄失效
它不看文件内容，只认文件路径。一旦构建系统或 IDE 做了路径别名、symlink、submodule 嵌套、或者用了 -I 把同一目录加了多次，就可能漏判。
典型表现：头文件内容没变，但某次编译突然报 duplicate symbol，重启构建或清理缓存后又好了——这往往是路径判定不稳定导致的。
- 避免在
include路径中混用相对路径和绝对路径引用同一头文件 - CMake 中慎用
target_include_directories(... PRIVATE)和PUBLIC混搭，容易造成头文件被多条路径命中 - CI 环境中若挂载了网络文件系统（NFS），
#pragma once的 inode 判断可能异常
头文件里写了 #pragma once 还要写宏卫士吗
不需要双写。但现实中不少项目保留“双重防护”，本质是历史惯性或防御性编程——其实只要确认编译器支持且路径管理干净，单用 #pragma once 更安全：宏卫士写错宏名、漏 #endif、宏名重复，都会引入更难排查的问题。
真正关键的是统一团队规范，而不是叠加保险。
- 如果已有大量
#ifndef宏卫士，不必强行改成#pragma once - 新写的头文件，优先写
#pragma once，除非明确知道要支持某款不支持它的编译器 - 检查是否生效？加一行
#error "included"在头文件开头，多包含几次，看报错次数是否只有一次
复杂点在于：头文件重复包含本身常是设计问题的表象。比如一个模块头文件无节制暴露内部实现，被到处 #include，这时光靠 #pragma once 挡不住编译慢、依赖爆炸、重构困难——它只是止血贴，不是手术刀。
