一、查找的目录不同1、#编译器直接从系统类库目录里查找头文件#include比如说那个当中的情况, 编译器会直接在名为\VC\的目录之下查找找到stdio.h这个文件, 这便是编译器对应的类库目录处于Linux GCC编译环境的时候, 一般而言是/usr/那个目录以及/usr/local/这个目录。万一在类库目录那儿查找的时候失败了, 那么编译器就会不再继续查找, 而是直接给出报错信息: No such file or。比如说, 我们自行定义了一个头文件, 名为“test.h”, 我们将它放置在项目工程文件所处的目录那里, 接着呢, 采用“# ”这样的形式去加载头文件test.h, 而到了编译的时候, 居然会直接出现报错的情况,报错内容为: No such file or。2、所谓项目当前目录, 乃是项目工程文件*.所在的那个目录, 默认是从该项目当前目录去查找头文件的, 就如同下面这个图示所展现的那样:要是在当做项目当时路径所处地方进行查找时出现失败情况, 接着便从项目所配置的头文件引用至目录那儿去查找头文件, 所说的项目配置的引用目录, 指的就是我们于项目工程里来设置的头文件引用目录, VS编译环境呈现出如下这般的样子。在Linux GCC编译环境之下, 则通常是借助于在文件当中运用-L参数进而指定引用目录。若是项目配置的头文件引用目录当中依旧查找失败, 那就再于系统类库目录里去查找头文件, 所以, 针对系统库头文件, #以及#的作用是相同的, 都能够查找成功。#include //#includestdio.h //效果一样注意, 尽管#的查找范围更为广泛, 可这并非表明, 不管是系统头文件、自定义头文件, 均可一概用#来包含。因为#的查找顺序有先后之分, 要是项目当前目录或者引用目录下存在与系统目录下重名的头文件, 那么编译器在当前目录或者引用目录查找成功后, 便不会再继续查找, 故而存在头文件覆盖的问题。另外, 对于系统头文件, 使用#包含, 查找时一步到位, 程序编译时的效率也会相对更高些。二、使用场景不同1、通常是被用来涵盖系统头文件, 像是.h、stdio.h这类的。2、一般而言, 其被用来涵盖自定义头部文件, 举例来说, 像是咱们自行定义的test.h, 以及.h这类。