按照标准-是的，它们是不同的：

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

注意，标准没有说明实现定义的方式之间的任何关系。第一个表单以一种实现定义的方式进行搜索，另一个表单以（可能是其他）实现定义的方法进行搜索。该标准还规定应存在某些包含文件（例如，<stdio.h>）。

从形式上讲，您必须阅读编译器的手册，但通常（按照传统）#include“…”表单会搜索首先找到#include的文件目录，然后搜索#include<…>的目录表单搜索（包括路径，例如系统标题）。

它确实：

"mypath/myfile" is short for ./mypath/myfile

具有是#include所在文件的目录和/或编译器的当前工作目录，和/或default_include_path

and

<mypath/myfile> is short for <defaultincludepaths>/mypath/myfile

如果./在<default_include_paths>中，则不会有任何区别。

如果mypath/myfile位于另一个include目录中，则行为未定义。

这里的许多答案都集中在编译器搜索文件的路径上。虽然这是大多数编译器所做的，但一个符合标准的编译器可以使用标准头的效果进行预编程，并将#include＜list＞视为一个开关，它根本不需要作为一个文件存在。

这不是纯粹的假设。至少有一个编译器可以这样工作。建议仅对标准标头使用#include<xxx>。

<file>include告诉预处理器首先在-I目录和预定义目录中搜索，然后在.c文件的目录中搜索。“file”include告诉预处理器首先搜索源文件的目录，然后返回到-I并预定义。无论如何都会搜索所有目的地，只是搜索顺序不同。

2011年标准主要讨论了“16.2源文件包含”中的包含文件。

2表单的预处理指令#包含<h-char-sequence>新行在实现定义的位置序列中搜索由在<和>分隔符之间指定的序列，并导致用标题的全部内容替换该指令。如何指定位置或标识标题定义了实现。3表单的预处理指令#包括“q-char-sequence”新行导致将该指令替换为在“分隔符”之间指定的序列。命名的源文件是以实现定义的方式搜索。如果此搜索是不受支持，或者如果搜索失败，指令将被重新处理为如果它读#包含<h-char-sequence>新行与原始指令相同的包含序列（包括>个字符，如果有）。

请注意，如果找不到文件，“xxx”格式将降级为<xxx>格式。其余部分由实现定义。

#include＜＞用于预定义的头文件

如果头文件是预定义的，那么您只需将头文件名写在尖括号中，它看起来像这样（假设我们有一个预定义的头文件名iostream）：

#include <iostream>

#include“”表示程序员定义的头文件

如果你（程序员）编写了自己的头文件，那么你会将头文件名用引号括起来。因此，假设您编写了一个名为myfile.h的头文件，那么这是如何使用include指令包含该文件的示例：

#include "myfile.h"

有两种方法可以编写#include语句。它们是：

#include"filename"
#include<filename>

每种形式的含义是

#include"mylib.h"

该命令将查找当前目录中的文件mylib.h以及可能已设置的include搜索路径中提到的指定目录列表。

#include<mylib.h>

此命令将仅在指定的目录列表中查找文件mylib.h。

include搜索路径只是一个目录列表，可以搜索包含的文件。不同的C编译器允许您以不同的方式设置搜索路径。