Arduino开发中依赖库已被上层库包含为何仍需重复引入

首先你的实测结论是完全正确的：在现行Arduino IDE（1.8.x及以上版本）中，只要主库已经在自身头文件内正确包含了依赖库头文件，且你的业务代码没有直接调用依赖库的接口，不重复写依赖库的#include语句完全可以正常编译运行，不存在“不引入就不会被编译”的问题。
你看到的那个论坛说法，是Arduino 1.0.x及更早老版本IDE的遗留问题：当时IDE的构建系统只会扫描草图文件里直接写的#include语句，不会递归解析库内部的包含关系，经常出现依赖漏编译的报错，这个bug在2014年前后的版本更新中就已经修复了。

官方示例以及大量成熟项目代码坚持显式引入所有依赖（哪怕依赖已经被其他库内部包含），核心原因有三个：

• 版本兼容兜底：并非所有第三方库都遵循规范的头文件写法，不少老旧第三方库会把依赖的#include写在.cpp实现文件而非公开的.h头文件中，或是通过条件编译宏控制依赖的启用。这种情况下如果不在草图中显式引入依赖，碰到特定库版本、特定编译配置时就会随机出现未定义报错，把依赖直接写在草图头部可以绕开绝大多数这类不规范实现带来的兼容问题。
• 降低维护成本：“显式告知依赖关系”并不是一句空话。当你或其他开发者后续迭代代码时，不需要逐层点进库文件翻找依赖关系，只看草图头部的引入列表就能快速知道项目用了哪些总线、哪些组件，比如看到#include <SPI.h>就知道项目用到了SPI总线，排查硬件冲突、修改总线配置时可以直接定位，不用做无意义的全局检索。如果后续替换主库（比如把SD卡库换成其他存储方案），也能快速判断哪些关联依赖可以一并删除。
• 规避隐式依赖断裂风险：库的迭代过程中可能调整依赖逻辑，比如未来SD库如果升级为支持SPI/SDIO多种通信方式、把SPI改为可选依赖，如果你之前在代码里直接调用过SPI接口但没有显式引入SPI.h，升级库之后就会直接出现编译报错。显式引入所有你代码直接、间接用到的库，不管它是不是被其他库顺带引入，能从根源上避免上层库迭代带来的依赖断裂问题。

你提到的SD库官方示例写法如下：

#include <SD.h>  // SPI.h已在SD.h内部被包含
#include <SPI.h> // 显式引入做兼容、维护性兜底

日常写个人测试项目时，如果你确认自己用的库写法规范、自己也不会直接调用依赖库的接口，完全可以省略重复的引入语句，不会影响功能。但官方示例需要覆盖所有用户的使用场景，兼容从老版本到新版本的所有IDE、库版本，还要给新手做最稳妥的写法示范，因此会坚持把所有依赖显式列在文件头部。

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