#include与软链接的交互及引号包含的头文件搜索路径问题

首先得明确：C/C++标准并没有对符号链接（软链接）在头文件包含中的行为做出强制规定，这属于编译器的实现定义行为——简单说，不同编译器甚至同一编译器的不同选项，结果可能不一样。不过主流编译器（比如GCC、Clang）有比较一致的默认逻辑，结合你的场景来拆解：

你的目录结构是：

• 当前工作目录（CWD）：a.h、b.h
• 子目录d：c.h、软链接b.h（指向CWD的b.h）

流程是：c.h用#include "b.h"包含软链接的b.h，然后b.h用#include "a.h"包含a.h。

默认行为（以GCC/Clang为例） #

主流编译器默认会解析软链接到真实物理路径：

1. 当编译时处理c.h里的#include "b.h"，编译器会找到d/b.h这个软链接，然后解析它的真实路径是CWD/b.h。
2. 接下来处理b.h里的#include "a.h"时，引号包含的优先搜索目录是**b.h的真实物理目录（也就是CWD）**，所以会直接找到CWD下的a.h，不会去d目录搜索。

可选的非默认行为 #

如果给编译器加上特定选项（比如GCC的-fno-canonicalize-headers），编译器会保留软链接的路径作为包含目录：

1. 处理c.h的#include "b.h"时，编译器会把d目录当作b.h的“包含目录”，而不解析到真实路径。
2. 这时候b.h里的#include "a.h"会先在d目录搜索，找不到a.h的话，才会继续搜索其他路径（比如CWD，如果它在编译器的搜索路径里）。

总结 #

• 默认情况下，a.h会在b.h的真实物理位置（CWD）被找到；
• 如果启用了保留软链接路径的编译选项，才会先在d目录搜索a.h。

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