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

So

#包含<myFilename>

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

#包括“myFilename”

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

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

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

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

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

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

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

预处理器的确切行为因编译器而异。以下答案适用于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目录。

不同的是预处理器搜索要包含的文件的位置。

#include＜filename＞预处理器以实现定义的方式进行搜索，通常在编译器/IDE预先指定的目录中进行搜索。此方法通常用于包含C标准库的头文件和与目标平台相关联的其他头文件。#include“filename”预处理器也以实现定义的方式进行搜索，但通常用于包括程序员定义的头文件，并且通常包括与包含指令的文件相同的目录（除非给出了绝对路径）。

对于GCC，可以在GCC文档中找到关于搜索路径的更完整描述。

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

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