为何苹果不建议在框架头文件中使用@import语法？

1. 强制客户端启用模块依赖，降低兼容性 #

• @import 是Clang模块系统的专属语法，要求编译时必须开启 -fmodules 选项。如果框架的公开头用了这个语法，所有集成该框架的客户端项目都必须启用模块支持（也就是Xcode里的Enable Modules (C and Objective-C)选项），否则会直接编译失败。
• 对比传统的 #import <ModuleName/ModuleName.h>，它不需要强制客户端开启模块，兼容更多场景——比如老项目、自定义构建脚本未配置模块的项目，都能正常编译。

2. 模块验证器（ENABLE_MODULE_VERIFIER）的严格检查 #

• 开启 ENABLE_MODULE_VERIFIER 后，Xcode会严格校验模块的定义和使用规范，目的是避免模块依赖混乱、符号冲突等问题。
• 框架公开头里的 @import 会被判定为“不恰当的依赖暴露”：模块系统的设计初衷是让框架内部管理依赖，而不是通过公开头把模块语法强加给客户端。这种写法会破坏模块封装性，验证器会直接抛出错误。

3. 混合语言项目的潜在兼容风险 #

• 对于Objective-C和Swift混合的框架，@import 在公开头中可能导致Swift桥接出现问题：Swift对模块的解析逻辑和Objective-C存在差异，公开头的@import可能让Swift无法正确识别依赖模块的符号，或者引发桥接文件的编译错误。
• 比如，当依赖的模块同时包含Objective-C和Swift代码时，@import 可能导致符号重复定义、可见性冲突等难以排查的问题。

4. 非标准语法的可移植性问题 #

• @import 是Clang/LLVM的扩展语法，不属于标准C/Objective-C规范。如果你的框架需要被非Xcode编译器（比如某些嵌入式场景的GCC）编译，@import 会直接触发语法错误，而#import是标准语法，跨编译器兼容性更好。

解决建议 #

• 将公开头中的 @import MODULE_NAME; 替换为传统的 #import <MODULE_NAME/MODULE_NAME.h>；
• 如果是框架内部使用的依赖，将导入语句移到.m/.mm实现文件或私有头文件中，不要暴露在公开接口里。

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