可能重复：
what is the difference between #include <filename> and #include “filename”
除了编译器将搜索的路径之外，这两种#include 语法之间是否存在根本区别？
我感觉 Intel 的编译器并没有给出完全相同的输出。
【问题讨论】：
标签： c++ compiler-construction include
根本区别是搜索路径。
您应该对“系统”包含使用尖括号形式，对项目本地包含使用常规引号。
【讨论】：
C 语言标准规定<> 用于“标题”，"" 用于“源文件”。现在，不要对“源文件”这件事大发雷霆。当标准说“源文件”时，它并不意味着你的想法。标准中使用的术语“源文件”包括我们通俗地称为“头文件”（除了我们通常所说的“源文件”）。
当标准谈论“标题”时，它根本不是专门谈论文件。该标准不要求标头作为文件存在。它们可以内置到编译器中，用于所有标准的关心。
所以<>和""之间的真正区别在于<>用于headers而""用于文件。如果您知道要包含的源是一个文件，那么您应该使用""。
实际上，编译器对<> 和"" 使用不同的搜索算法。这是标准允许的，因为用于任一搜索算法的搜索算法是实现定义的。但这并不是标准所表达的真正区别。
【讨论】：
Dan Molding 做对了；放松，黑客，尼克巴斯汀弄错了。对不起。
#include <...>
用于headers，它甚至不需要是文件系统中的文件，但可以例如在编译器内部。
#include "..."
用于文件，只有在找不到此类文件时，才会默认返回#include <...>。
这些头文件和文件的查找方式和位置，系统文件是否应该使用，项目文件是否应该使用“”，这确实是一个常见的约定，完全取决于编译器和项目.
C 标准 (ISO/IEC 9899:1999) 说（强调我的）：
6.10.2 源文件包含
约束
#include指令 应标识头文件或源文件 可以处理的 实施。语义
表单的预处理指令
#include <h-char-sequence> new-line搜索一个序列 a 的实现定义的位置 唯一标识的标头 之间的指定序列 分隔符，并导致替换 该指令由整个 标头的内容。地方如何 已指定或标头已标识 是实现定义的。
表单的预处理指令
#include "q-char-sequence" new-line导致替换那个 指令的全部内容 由 之间的指定序列 分隔符。命名的源文件是 以 > 实现定义的方式搜索。 如果这 不支持搜索，或者如果 搜索失败，指令是 重新处理，好像它已阅读
#include <h-char-sequence> new-line具有相同的 包含的序列（包括 > 字符，如果有的话）从原始 指令。
【讨论】：
引号 指示首先在当前目录中搜索，然后在系统目录中搜索（在编译器/预处理器中硬编码或使用-I 指定的路径）。通过使用尖括号，您首先选择不搜索当前目录。
编译器输出绝对不依赖于引号，因为它是在预处理阶段处理的。除了由于搜索行为改变而包含不同文件的情况。
【讨论】：
对于 gcc 编译器， 和 "" 标头之间存在 区别。如果从作为 -isystem 提供给预处理器的目录中包含 标头，则不会针对包含的标头发出警告。使用 -Werror，这在某些情况下会产生巨大的影响。
英特尔编译器也有 -isystem 指令，因此它可能也适用于 icc。
更不用说查找目录的差异太明显了。
【讨论】：
#include <somefile.h>
将检查系统包含路径（包括为项目添加的任何其他路径）。
#include "somefile.h"
将检查应用程序工作文件夹。 （即与其中包含#include 语句的源文件相同的文件夹）。
【讨论】：
警告：这纯属猜测。我对英特尔编译器没有足够的经验来知道它是否以这种方式工作，我也不知道有任何编译器可以这样做。
如果编译器实现了预编译的头文件，它可能会将它们用于一种形式的包含而不是另一种。如果预编译的标头与实际标头不同步，您会得到不同的结果，具体取决于包含的内容。
【讨论】：
一般来说没有技术差异，任何人告诉你的一切都只是本地风格，可能受到过去编译器的影响 - 许多现代编译器以完全相同的方式实现初始搜索（通常其他常见行为可通过命令行获得选项）。该标准将行为留给了实现者，没有特别的理由来支持这两种语法。
根据 ISO C99 标准的第 6.10.2 节， 和“”的搜索路径都是实现定义的。在标准看来，它们之间的唯一区别是如果无法解决，使用 "" 将退回到 。 （不要被似乎区分“头文件”和“源文件”的标准所迷惑——除了保留某些名称这一事实之外，标准实际上没有定义任何区别——“stdio.h "等)
【讨论】：