pragma once不能完全替代宏保护，因其非标准且在符号链接、多路径包含等场景可能失效；宏保护依赖预处理器严格匹配，工业级项目仍强制使用。
为什么#pragma once不能完全替代宏保护
#pragma once确实能阻止头文件重复包含，但它的行为依赖编译器实现，不是C++标准的一部分。GCC、Clang、MSVC都支持，但某些嵌入式工具链或老版本编译器（比如早期IAR、Keil ARMCC）可能忽略它，或在符号链接、硬链接、网络文件系统路径下判断失效——这时#include "header.h"通过不同路径被引入两次，#pragma once就可能失效。
宏保护则靠预处理器严格匹配宏名，只要宏名唯一且定义位置合理，就100%生效。所以工业级项目（如Linux内核、Chromium）仍强制要求宏保护，#pragma once最多作为辅助。
- 宏名必须全局唯一：推荐用
PROJECT_MODULE_FILENAME_H_格式，比如MYLIB_UTILS_STRING_H_ - 宏定义必须放在头文件最开头，且紧贴
#ifndef之后，中间不能有空行或注释（某些旧预处理器会出错） - 不要在宏名里用
__FILE__或__LINE__生成，会导致同一文件多次包含时宏不等效
宏保护的标准写法和常见翻车点
正确结构是三行固定模式：#ifndef → #define → #endif，缺一不可。漏掉#define会导致条件始终为真，整个头文件被跳过；漏掉#endif会破坏后续所有头文件的预处理逻辑。
典型错误示例：
立即学习“C++免费学习笔记（深入）”；
#ifndef FOO_H #define FOO_H // ... 内容 // 忘了 #endif！
更隐蔽的问题是宏名冲突：比如两个第三方库都用了COMMON_H，就会互相屏蔽。解决方法是加项目前缀，或用UUID生成器生成长宏名（如ABCD1234_EF56_7890_GHIJ_KLMNOPQRSTU_），但实际开发中前缀足够可靠。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
什么时候可以只用#pragma once
如果你明确控制全部构建环境（比如内部工具链、CI用Docker固定镜像、团队统一VS2019+），且不需要导出头文件给外部使用，#pragma once是更简洁的选择——它不污染宏命名空间，不会因宏名拼写错误导致静默失败，也没有宏展开的意外副作用。
但要注意：它对“相同物理文件但不同路径”的识别能力有限。例如：
#include "src/utils.h"#include "../project/src/utils.h"
这两个路径指向同一文件，但某些编译器可能认为是两个不同文件，从而触发重复包含。此时宏保护依然有效，#pragma once可能失效。
现代项目的推荐组合写法
双保险最稳妥：先写#pragma once，再套一层宏保护。预处理器会先检查#pragma once，命中缓存就跳过；未命中时再走宏判断。两者不冲突，且不影响编译速度。
示例vector_math.h开头：
#pragma once
#ifndef MATH_VECTOR_MATH_H_
#define MATH_VECTOR_MATH_H_
#include <cmath>
namespace math {
struct Vec3 { float x, y, z; };
} // namespace math
#endif // MATH_VECTOR_MATH_H_
真正容易被忽略的是：宏名末尾的_不是装饰，而是避免与用户可能定义的MATH_VECTOR_MATH_H变量/宏冲突。下划线结尾是POSIX和C++标准库的通用惯例，别省略。
