17、头文件保护：#ifndef/#define/#endif与#pragma once的选择
头文件保护，说白了就是防止同一个头文件被编译器反复解析。你想想看，一个工程里几百个头文件，A包含了B，B又包含了C，C反过来又引用了A——如果没有保护机制，编译器直接原地爆炸。
我刚开始写C的时候，就吃过这个亏。那时候刚入行，头文件里没加保护，结果编译报了一堆“重复定义”的错误，我愣是排查了一下午。后来老员工看了一眼，淡淡说了句：“加个头文件保护。”嗯，从那以后，我再也没忘过。
两种主流方案
目前业界就两种做法：#ifndef/#define/#endif 和 #pragma once。咱们一个一个说。
1. #ifndef/#define/#endif
这是C89标准就支持的写法，跨平台性最好。任何编译器都能认。
// my_module.h
#ifndef MY_MODULE_H
#define MY_MODULE_H
/* 你的代码在这里 */
#endif /* MY_MODULE_H */它的原理很简单：第一次包含时，MY_MODULE_H没定义，所以进入代码段，同时定义了这个宏。第二次再包含时，MY_MODULE_H已经存在，预处理器直接跳过整个文件。
关键点：宏名必须唯一。我见过有人随便写个 _H_ 或者 HEADER_H，结果跟别的库冲突了。我个人习惯用 项目名_模块名_H 的格式，比如 PROJ_DRIVER_UART_H。
2. #pragma once
这是编译器提供的扩展指令。写法简洁到令人发指：
// my_module.h
#pragma once
/* 你的代码在这里 */就一行。编译器会记住这个文件的物理路径，下次再遇到直接跳过。我在项目中用过很多次，确实省事。
我的建议：如果你确定项目只在GCC、Clang、MSVC这几个主流编译器上跑，用 #pragma once 完全没问题。但如果你要写跨平台库，或者要兼容某些古老的嵌入式编译器，老老实实用 #ifndef。
对比表格
| 特性 | #ifndef/#define/#endif | #pragma once |
|---|---|---|
| 标准支持 | C89/C99/C11 全支持 | 非标准，编译器扩展 |
| 写法简洁度 | 三行代码，较啰嗦 | 一行搞定 |
| 宏名冲突风险 | 有（需手动保证唯一） | 无（基于文件路径） |
| 编译速度 | 预处理器仍需打开文件检查宏 | 编译器直接跳过，略快 |
| 可移植性 | 所有编译器 | 主流编译器，部分小众不支持 |
避坑指南
我曾经在一个项目里同时用了两种方式：头文件里写了 #ifndef，又在文件开头加了 #pragma once。你猜怎么着？编译器没报错，但代码审查的时候被怼了。没必要，真的没必要。选一种，坚持用下去。
注意：不要在同一头文件中混用两种保护机制。虽然不会出错，但会让维护者困惑。团队里统一规范比什么都重要。
还有一个坑：#pragma once 依赖文件路径。如果你在构建系统里用了符号链接或者硬链接，同一个文件可能被识别成不同路径，导致保护失效。我在一个CI环境里遇到过这个问题，排查了半天才发现是链接搞的鬼。
我的选择
我个人习惯这样：
- 嵌入式裸机项目：用
#ifndef。因为要兼容各种小众编译器，安全第一。 - Linux/Windows应用层：用
#pragma once。简洁，编译快，团队里大家都这么写。 - 开源库：用
#ifndef。你不知道用户会用啥编译器，别给自己找麻烦。
你想想看，头文件保护本身是个小问题，但选错了或者没加，后果很严重。我见过有人因为头文件保护没写好，导致整个工程编译时间翻了三倍。嗯，细节决定成败。
知识体系图
下面这张图帮你理清头文件保护的核心逻辑：
一句话总结：如果你不确定用哪个，就用 #ifndef。它永远不会背叛你。如果你追求简洁且编译器可控，#pragma once 是真香。
公众号:蓝海资料掘金营，微信deep3321