#pragma once：单次包含保证
头文件重复包含，这问题我早年栽过跟头。那时候项目大，头文件套头文件，结果编译报了一堆「redefinition」错误。排查了半天，才发现是同一个结构体被包含了两次。
解决这个问题，传统方案是头文件保护宏。但C99之后，编译器们搞了个更简洁的写法——#pragma once。今天咱们就聊聊这个。
什么是 #pragma once
说白了，它就是告诉编译器：「这个文件，只处理一次」。不管你在多少个地方#include它，编译器只认第一回。
// my_header.h
#pragma once
typedef struct {
int id;
char name[32];
} MyStruct;就这么一行。放在文件最开头，后面想怎么include都行，不会重复定义。
与头文件保护宏的对比
传统做法是用宏来防重复：
// my_header.h
#ifndef MY_HEADER_H
#define MY_HEADER_H
typedef struct {
int id;
char name[32];
} MyStruct;
#endif /* MY_HEADER_H */两种方式都能解决问题。但区别在哪？我列个表给你看：
| 对比项 | #pragma once | 头文件保护宏 |
|---|---|---|
| 代码量 | 一行 | 三行（#ifndef/#define/#endif） |
| 命名冲突风险 | 无 | 宏名可能重复 |
| 编译器支持 | 主流都支持，但不是标准 | 所有C编译器都支持 |
| 编译速度 | 略快（编译器直接跳过） | 略慢（需要展开宏判断） |
| 跨平台性 | 部分老旧编译器不支持 | 完全跨平台 |
我的建议：新项目用#pragma once，维护老项目保持头文件保护宏。如果项目需要移植到非常老旧的编译器，那就老老实实用宏。
跨平台问题
嗯，这里要注意。#pragma once不是C标准的一部分。它是各家编译器自己扩展的。
主流编译器都支持：
- GCC：从3.4版本开始支持
- Clang：一直支持
- MSVC：从Visual Studio 2005开始支持
- ICC（Intel编译器）：支持
但有些场景会出问题：
我曾经遇到过一个坑：在某个嵌入式编译器上，#pragma once对符号链接的文件失效。同一个文件通过不同路径访问，编译器认为它们是不同的文件，结果还是重复包含了。
还有，某些编译器对网络文件系统（NFS）上的文件，#pragma once可能识别不了。因为文件路径的比对方式不同。
最佳实践
我个人习惯这样用：
// config.h
#pragma once
#ifndef CONFIG_H
#define CONFIG_H
// 你的代码写在这里
#endif /* CONFIG_H */你可能会问：「这不是多此一举吗？」
其实不是。这样写有两个好处：
- 主流编译器看到
#pragma once，直接跳过文件，编译更快 - 遇到不支持
#pragma once的编译器，保护宏兜底
这叫「双保险」。我在做跨平台SDK时，所有头文件都这么写。不管是Windows、Linux还是RTOS，从来没出过问题。
SVG：头文件包含控制流程
实际项目中的选择
我参与过一个车载嵌入式项目，编译器是Green Hills的。它支持#pragma once，但文档里写了一句：「在部分文件系统上可能失效」。项目经理看到这句话，直接拍板：「全部用头文件保护宏」。
你想想看，汽车上跑的程序，出问题可不是闹着玩的。所以在这种场景下，宁可多写几行代码，也要保证万无一失。
反过来，如果是做手机App的底层库，用#pragma once完全没问题。Clang和GCC的支持非常稳定。
小技巧：如果你不确定目标编译器是否支持#pragma once，可以写个测试文件，故意重复包含两次，看看会不会报错。我在接手一个新平台时，第一件事就是做这个测试。
总结
#pragma once是个好东西，简洁高效。但它不是银弹。理解它的原理和局限，才能用好它。
我个人倾向：
- 个人项目、小团队项目：直接用
#pragma once - 大型项目、跨平台项目：双保险写法
- 安全关键系统、老旧平台：头文件保护宏
记住一点：工具是为人服务的。别为了炫技，把简单问题搞复杂了。
公众号:蓝海资料掘金营，微信deep3321