在Objective-C项目中使用静态库时出现框架头文件未找到错误

这个问题我之前帮团队排查过好几次，核心原因是静态库的头文件引用逻辑和主项目通过CocoaPods引入框架的路径没有对齐，下面给你一步步拆解解决方案：

1. 先确认最容易踩的低级错误 #

• 确保你打开的是App_D的.xcworkspace文件，而不是.xcodeproj。CocoaPods生成的依赖只有在workspace里才会被正确加载，直接打开项目文件肯定找不到框架。
• 检查Podfile里是否确实添加了framework_B和framework_C，并且执行过pod install或pod update，Podfile.lock文件里能看到这两个框架的版本记录。

2. 调整主项目App_D的头文件搜索路径 #

编译报错本质是编译器找不到framework_B/framework_B.h的位置，需要把CocoaPods的路径告诉编译器：

• 打开App_D的Target → Build Settings → 搜索Header Search Paths
• 添加路径$(PODS_ROOT)/framework_B，并且把后面的选项设置为Recursive（递归搜索，确保能找到子目录里的头文件）
• 同样的，在Framework Search Paths里也添加$(PODS_ROOT)/framework_B，因为框架本身的二进制文件也需要被搜索到

3. 修改静态库lib_A的头文件引用方式 #

如果上面的配置还是不行，可以尝试修改lib.h里的引用语法：

• 把原来的#import <framework_B/framework_B.h>改成模块化引用：@import framework_B;
  模块化引用是Apple推荐的方式，会自动处理框架的路径依赖，只要主项目正确引入了框架，编译器就能识别到。
• 如果你不想用模块化，也可以改成相对引用#import "framework_B.h"，但前提是头文件搜索路径已经配置正确。

4. 检查静态库本身的编译配置（如果是你自己构建的lib_A） #

如果lib_A是你自己编译的静态库，要确保：

• 编译lib_A时，framework_B和C的路径已经被添加到静态库的Header Search Paths和Framework Search Paths中，避免静态库的头文件硬编码了错误的路径。
• 静态库的Public Headers只包含你需要暴露给App_D的头文件（也就是lib.h），不要把framework_B的头文件也打包进去，否则会导致路径冲突。

一般来说，先排查第1点（是否打开workspace），再调整第2点的搜索路径，大部分情况下就能解决问题了。

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