#pragma一次允许编译器在再次出现该文件时完全跳过该文件——而不是解析该文件，直到它到达#include守卫。

因此，语义略有不同，但如果它们按照预期的方式使用，则它们是相同的。

两者结合可能是最安全的方法，因为在最坏的情况下(编译器将未知的pragma标记为实际错误，而不仅仅是警告)，你只需要删除#pragma本身。

当你限制你的平台，比如说“桌面上的主流编译器”，你可以安全地省略#include守卫，但我在这方面也感到不安。

OT:如果你有其他关于加速构建的技巧或经验可以分享，我很好奇。

我回答了一个相关的问题:

#pragma once确实有一个缺点(除了不是标准的)，那就是如果你在不同的位置有相同的文件(我们有这样的情况是因为我们的构建系统会四处复制文件)，那么编译器会认为这些是不同的文件。

我把答案也加在这里，以防有人被这个问题绊倒，而不是其他问题。

在Konrad Kleine的解释之上。

简要总结:

当我们使用# pragma一次时，编译器的责任很大，不允许它被包含多次。这意味着，在您在文件中提到代码片段之后，就不再是您的责任了。

现在，编译器在文件的开头寻找这个代码片段，并跳过它不被包含(如果已经包含一次)。这肯定会减少编译时间(在一般和大型系统中)。然而，在模拟/测试环境中，由于循环等依赖关系，将使测试用例的实现变得困难。

现在，当我们为头文件使用#ifndef XYZ_H时，维护头文件的依赖关系更多地是开发人员的责任。这意味着，每当由于一些新的头文件，有循环依赖的可能性，编译器只会在编译时标记一些“未定义的..”错误消息，由用户检查实体的逻辑连接/流程，并纠正不适当的包含。

这肯定会增加编译时间(因为需要纠正和重新运行)。此外，由于它是在包含文件的基础上工作的，基于“XYZ_H”定义状态，如果不能获得所有定义，仍然会报错。

因此，为了避免这种情况，我们应该使用，as;

#pragma once
#ifndef XYZ_H
#define XYZ_H
...
#endif

即两者的结合。

我不认为它会对编译时间产生重大影响，但#pragma once在所有编译器中都得到了很好的支持，但实际上并不是标准的一部分。预处理器可能会快一点，因为它更容易理解你的确切意图。

#pragma一次性使用不太容易出错，需要输入的代码也更少。

为了加快编译时间，尽可能地向前声明而不是包含在.h文件中。

我更喜欢使用#pragma一次。

这篇维基百科文章介绍了两者同时使用的可能性。

如果你确信你永远不会在不支持它的编译器中使用这段代码(Windows/VS, GCC和Clang是支持它的编译器的例子)，那么你当然可以使用#pragma一次而不用担心。

您也可以两者都使用(参见下面的示例)，这样就可以在兼容系统上获得可移植性和编译加速

#pragma once
#ifndef _HEADER_H_
#define _HEADER_H_

...

#endif

我认为你应该做的第一件事是看看这是否真的会产生影响。您应该首先测试性能。谷歌上的一个搜索结果是这样的。

在结果页面中，对我来说，列是缓慢的，但很明显，至少到VC6，微软没有实现其他工具正在使用的包括保护优化。当include守卫是内部的时候，它花费的时间是外部守卫的50倍(外部包含守卫至少和#pragma一样好)。但让我们考虑一下这可能产生的影响:

根据给出的表格，打开include并检查它的时间是使用#pragma的等效时间的50倍。但在1999年，每个文件的实际时间是1微秒!

那么，一个TU会有多少重复的头?这取决于你的风格，但如果我们说平均每个TU有100个副本，那么在1999年，我们可能要为每个TU支付100微秒。随着HDD的改进，现在这个数字可能会显著降低，但即使是这样，通过预编译头文件和正确的依赖关系，跟踪一个项目的累计成本几乎肯定是你构建时间中微不足道的一部分。

现在，在另一方面，可能不太可能，如果你曾经移动到一个不支持#pragma的编译器，那么考虑一下要花多少时间来更新你的整个源代码库，以包含守卫而不是#pragma?

微软没有理由不能像GCC和其他编译器一样实现包含保护优化(实际上有人能确认他们的最新版本是否实现了这一点吗?)恕我直言，#pragma once除了限制你对可选编译器的选择外，几乎没有什么作用。