头文件需防止重复包含，因多源文件或嵌套包含会导致同一定义被多次处理，引发redefinition错误；标准做法是用#ifndef/#define/#endif宏守卫或#pragma once指令防护。
为什么头文件需要防止重复包含
当多个源文件都 #include 同一个头文件，或头文件之间互相包含时，编译器可能多次看到同一组类型定义、函数声明或模板代码。这会触发 redefinition 错误——比如 error: redefinition of 'struct Foo'。预处理阶段的“防重包含”不是可选项，而是必须项。
#ifndef 的写法和常见错误
标准、可移植、可控，但依赖宏名不冲突。典型结构是：
#ifndef MY_HEADER_H #define MY_HEADER_H // 头文件内容 #endif
关键点：
- 宏名应全局唯一，推荐用路径+文件名大写+下划线形式，如
UTILS_STRING_UTILS_H；用MY_HEADER_H这类泛化名极易撞车 - 必须在头文件最顶部（早于任何 #include 或声明），否则前置的声明可能已被展开多次
- 不能漏掉
#define行，否则条件永远为真，起不到防护作用 - 嵌套包含时，外层头文件的
#ifndef不会自动保护内层——每个头文件都得自己加
#pragma once 的适用场景和限制
由编译器直接识别，语义更干净，且能避免宏名污染。但它不是 C++ 标准特性，只是所有主流编译器（MSVC、Clang、GCC）都支持的事实标准。
要注意：
- 对符号链接、硬链接或网络文件系统（如某些 NFS 配置）下相同物理文件的多个路径，
#pragma once可能失效——编译器按路径字符串判重，而非文件 inode - 某些构建系统（如旧版 CMake + 某些交叉工具链）或静态分析工具可能忽略它
- 不能替代
#ifndef实现条件编译逻辑（比如#ifdef DEBUG套在#pragma once外面是无效的）
该选哪个？实际项目中的混合策略
大型跨平台项目通常采用双保险写法：
#pragma once #ifndef MY_HEADER_H #define MY_HEADER_H // 内容 #endif
这样既享受 #pragma once 的简洁和 inode 安全性，又保留标准兼容兜底。不过要注意：
- 顺序不能反——
#pragma once必须在#ifndef之前，否则预处理器可能已展开宏导致#ifndef失效 - 如果团队明确只支持 Clang/GCC/MSVC 且无特殊文件系统要求，单用
#pragma once更轻量、不易出错 - 只要用了其中一种，就别在同一头文件里混用两套独立的
#ifndef块，容易漏删导致静默失效
真正容易被忽略的是：即使加了防重包含，模板定义、内联函数或 constexpr 变量若在头文件中定义（而非仅声明），仍需确保 ODR 合规——这不是防重包含能解决的。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
