g++ 4.7/5.4加-I.时尖括号#include忽略文件名大小写是否为预期行为？

没错，你遇到的这个情况是GCC 4.7及以上版本的预期行为，背后是编译器对头文件查找的大小写处理逻辑做了调整，具体细节如下：

核心规则说明 #

当使用尖括号#include <file>引入头文件时：

• 没加-I选项时：编译器会优先在系统默认的头文件路径（比如Ubuntu的/usr/include）中查找，此时严格区分文件名大小写，所以能正确匹配系统自带的signal.h。
• 添加-I.选项后：当前目录被加入了优先搜索的头文件路径列表。GCC 4.7及以上版本在处理-I指定的路径时，会忽略文件名的大小写进行查找——这就导致<signal.h>会匹配到你本地的Signal.h，哪怕两者大小写不一致。

为什么会有这个调整？ #

这个变化是为了提升跨平台兼容性：在不区分大小写的文件系统（比如Windows的NTFS）上，开发者不用纠结头文件名的大小写就能正确引入文件。但在Ubuntu这类使用区分大小写文件系统（ext4）的系统上，就会出现你遇到的这种“大小写不匹配却被匹配到”的情况。

如何避免这个问题？ #

如果你想避免这种意外匹配，可以试试这些方法：

• 统一本地头文件的文件名大小写，让#include的文件名和实际文件名完全一致（比如把Signal.h改成signal.h，或者反过来）。
• 引入本地头文件时，优先使用双引号#include "signal.h"：这种方式下编译器会优先查找本地文件，且默认遵循文件系统的大小写规则，不会出现大小写不匹配的情况。
• 尽量避免用-I.把当前目录加入系统头文件搜索路径，除非确实有必要。

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