VS2017中自定义头文件#include "File"可用但#include <file>失败

这个问题我之前帮不少开发者排查过，核心是C/C++编译器对两种#include语法的查找逻辑不一样，咱们一步步来搞定：

先搞懂两种包含方式的本质差异 #

编译器处理这两种语法时，查找顺序是不同的：

• #include "myfile.h"：先在当前源文件所在的目录找头文件，找不到才会去你配置的「附加包含目录」、系统标准头文件目录里搜索
• #include <myfile.h>：默认优先去系统标准头文件目录查找，之后才会轮到你配置的附加包含目录（VS环境下的规则是这样）

为什么加了附加目录还是报错？ #

大概率是配置细节出了问题，你可以排查这几点：

• 路径是否正确：如果填的是相对路径，要确认它是相对于「项目目录」（右键项目→属性→常规里能看到），而不是解决方案目录或者其他路径；更稳妥的是用VS宏，比如你的头文件在项目下的custom_headers文件夹里，就填$(ProjectDir)custom_headers，这样项目移动后也不会失效
• 平台/配置是否匹配：比如你只在Debug x86里加了路径，但运行的是Release x64，这时候路径配置没同步，自然找不到
• 是否继承了默认设置：如果「附加包含目录」里没勾选「从父级或项目默认设置继承」，虽然不影响自定义路径，但偶尔会导致一些依赖问题，建议保持勾选

具体解决办法 #

根据你的需求，有几种可选方案：

• 方案一：修正附加包含目录配置
  重新检查路径，确保路径正确、平台/配置同步，用宏代替硬编码路径，这样基本就能解决<>找不到的问题
• 方案二：调整头文件查找顺序
  右键项目→属性→C/C++→高级，找到「强制包含文件」可以指定优先查找的头文件；或者在「附加包含目录」里把你的自定义路径拖到最顶部，让编译器先搜这个目录
• 方案三：推荐用""包含自定义头文件
  业界惯例里，<>一般用来包含系统标准库（比如#include <stdio.h>），""用来包含项目内的自定义头文件，这样代码可读性更强，也能避免这类查找顺序的问题

内容的提问来源于stack exchange，提问作者Sarfraz Ahmed