预处理器的确切行为因编译器而异。以下答案适用于GCC和其他几个编译器。

#include<file.h>告诉编译器在其“include”目录中搜索头文件，例如，对于MinGW，编译器将在C:\MinGW\include\或安装编译器的任何位置搜索file.h。

#include“file”告诉编译器在当前目录（即源文件所在的目录）中搜索文件。

您可以使用GCC的-I标志告诉它，当它遇到带有尖括号的include时，它还应该在-I之后的目录中搜索标头。GCC将把标志后面的目录当作includes目录。

例如，如果您在自己的目录中有一个名为myheader.h的文件，那么如果您使用标志-I调用GCC，可以说#include<myheader.h>。（表示应搜索当前目录中的includes。）

如果没有-I标志，则必须使用#include“myheader.h”来包含文件，或将myheader.h移动到编译器的include目录。

了解的唯一方法是阅读实现的文档。

在C标准第6.10.2节第2至4段中规定：

表单的预处理指令#包含<h-char-sequence>新行在实现定义的位置序列中搜索由<和>分隔符之间的指定序列唯一标识的头，并用头的全部内容替换该指令。如何指定位置或标识标题是实现定义的。表单的预处理指令#包括“q-char-sequence”新行导致用“分隔符”之间的指定序列标识的源文件的全部内容替换该指令。将以实现定义的方式搜索命名的源文件。如果不支持此搜索，或者搜索失败，则会像读取指令一样重新处理该指令#包含<h-char-sequence>新行具有与原始文件相同的包含序列（包括>个字符，如果有）指令。表单的预处理指令#包含pp令牌新行（与前两种形式之一不匹配）。指令中include之后的预处理标记与普通文本中的处理相同。（当前定义为宏名称的每个标识符由其预处理令牌的替换列表替换。）所有替换后产生的指令应与前两种形式之一匹配。实现定义了一种方法，通过该方法，<和>预处理令牌对或一对“字符”之间的一系列预处理令牌组合成单个标头名称预处理令牌。定义：h-char：源字符集的任何成员，除了换行符和>q-char：源字符集的任何成员，除了换行符和“

#包括＜文件名＞

预处理器以依赖于实现的方式进行搜索。它告诉编译器搜索系统头文件所在的目录。此方法通常用于查找标准头文件。

#包括“文件名”

这告诉编译器在程序运行的地方搜索头文件。如果失败，它的行为类似于#include＜filename＞，并在存储系统头文件的位置搜索该头文件。此方法通常用于标识用户定义的头文件（由用户创建的头文件）。如果您想调用标准库，请不要使用它，因为它比#include<filename>需要更多的编译时间。

感谢您的回答，特别是Adam Stelmaszczyk和piCookie，以及aib。

与许多程序员一样，多年来，我一直使用“myApp.hpp”格式作为应用程序特定文件，使用<libHeader.hpp>格式作为库和编译器系统文件（即/I和INCLUDE环境变量中指定的文件）的非正式约定，认为这是标准。

然而，C标准规定搜索顺序是特定于实现的，这会使可移植性变得复杂。更糟糕的是，我们使用了jam，它可以自动找出包含文件的位置。可以为包含文件使用相对路径或绝对路径。即

#include "../../MyProgDir/SourceDir1/someFile.hpp"

旧版本的MSVS需要双反斜杠（\\），但现在不需要了。我不知道什么时候变了。为了与'nix兼容，只需使用正斜杠（Windows将接受这一点）。

如果您真的担心这个问题，请使用“./myHeader.h”作为源代码所在目录中的包含文件（我当前的大型项目中有一些重复的包含文件名--这确实是一个配置管理问题）。

为了方便起见，这里复制了MSDN说明）。

引用的表单预处理器按以下顺序搜索包含文件：在与包含#include语句的文件相同的目录中。在当前打开的include文件的目录中，按以下相反顺序他们被打开了。搜索从父包含文件的目录开始继续向上通过任何祖父母包含文件的目录。沿着每个/I编译器选项指定的路径。沿着INCLUDE环境变量指定的路径。角钢支架形式预处理器按以下顺序搜索包含文件：沿着每个/I编译器选项指定的路径。在命令行上进行编译时，沿着INCLUDE环境变量指定的路径进行编译。

这里的一些好答案引用了C标准，但忘记了POSIX标准，特别是c99（例如C编译器）命令的特定行为。

根据开放组基础规范第7版，

-I目录更改搜索名称不是绝对路径名的标头的算法，以便在查找通常位置之前先查找由目录路径名命名的目录。因此，名称用双引号（“”）括起来的头应首先在文件的目录中搜索#include行，然后在-I选项中命名的目录中，最后在通常的位置搜索。对于名称用尖括号（“<>”）括起来的标题，只能在-I选项中命名的目录中搜索标题，然后在通常的位置搜索标题。应按照指定的顺序搜索-I选项中命名的目录。实现应在单个c99命令调用中支持至少十个此选项的实例。

因此，在符合POSIX的环境中，使用符合POSIX标准的C编译器，#include“file.h”可能会被搜索/首先是文件.h，其中。是包含#include语句的文件所在的目录，而#include＜file.h＞可能会首先搜索/usr/include/file.h，其中/usr/include是系统定义的头的常用位置（POSIX似乎没有定义）。

<和>之间的字符序列唯一地引用标头，而标头不一定是文件。实现可以随意使用字符序列。（不过，大多数情况下，只需将其作为文件名，并在include路径中进行搜索，正如其他帖子所述。）

如果使用#include“file”表单，则实现首先查找给定名称的文件（如果支持）。如果不支持（受支持），或者搜索失败，那么实现的行为就像使用了另一个（#include<file>）表单一样。

此外，存在第三种形式，当#include指令与上述任何一种形式都不匹配时，将使用第三种。在这种形式中，对#include指令的“操作数”进行了一些基本的预处理（如宏扩展），结果预计将与其他两种形式中的一种匹配。