#include <abc.h>

用于包含标准库文件。因此编译器将检查标准库头所在的位置。

#include "xyz.h"

将告诉编译器包含用户定义的头文件。因此编译器将在当前文件夹或-I定义的文件夹中检查这些头文件。

这里的一些好答案引用了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似乎没有定义）。

“<filename>”在标准C库位置搜索而“filename”也会在当前目录中搜索。

理想情况下，您可以使用＜…＞对于标准C库，“…”表示您编写的当前目录中的库。

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

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

编译器生成的实现定义的警告可以（并且将）以不同于程序库的方式对待系统库。

So

#包含<myFilename>

--它实际上声明myFilename位于系统库位置——很可能（而且可能会）隐藏死代码和未使用的变量警告等，当您使用：

#包括“myFilename”

GCC文件说明了两者之间的区别：

使用预处理指令“#include”包括用户和系统头文件。它有两种变体：#包含<文件>此变体用于系统头文件。它在系统目录的标准列表中搜索名为file的文件。您可以使用-I选项将目录添加到此列表中（请参阅调用）。#包含“文件”此变体用于您自己程序的头文件。它首先在包含当前文件的目录中搜索名为file的文件，然后在引号目录中搜索，然后在与＜file＞相同的目录中查找。您可以使用-iquote选项将目录添加到报价目录列表中。“#include”的参数（无论是用引号还是尖括号分隔）的行为与字符串常量相似，因为注释无法识别，宏名称也不会展开。因此，#include<x/*y>指定包含名为x/*y的系统头文件。然而，若反斜杠出现在文件中，则它们被视为普通文本字符，而不是转义字符。不处理适用于C中字符串常量的字符转义序列。因此，#include“x\n\\y”指定包含三个反斜杠的文件名。（有些系统将“\”解释为路径名分隔符。所有这些系统也以相同的方式解释“/”。仅使用“/”最为方便。）如果文件名后面的行中有任何内容（注释除外），则为错误。