如何在Swift中隐藏iOS模块化开发的静态库传递依赖项

方案1：自定义网络层静态库的模块映射（适配静态库场景） #

• 先确认网络层静态库target的Build Settings中Defines Module配置为YES，这是自定义模块映射的前提
• 手动创建一个自定义的module.modulemap文件，在Build Settings的Module Map File配置项中指向你创建的这个文件，替换Xcode自动生成的模块映射
• 自定义模块映射中仅声明你需要对外暴露的网络层公开头/模块，不要在export字段中声明Alamofire，也不要将Alamofire相关的头加入到网络层的umbrella公开头中
• 额外将Build Settings中的Build Libraries for Distribution设置为NO，避免Xcode自动导出所有依赖的第三方模块

方案2：限制Alamofire的引用作用域与接口透传 #

• 管理依赖时（SPM/CocoaPods/手动引入），仅将Alamofire关联到网络层静态库target，主应用和其他模块不要在自身的Link Binary With Libraries中添加Alamofire依赖
• 在网络层target的Build Settings中找到Other Swift Flags，添加-import-underlying-module参数，确保Alamofire仅被网络层内部识别引用
• 所有网络层的public/open级别的公开接口，绝对不能出现任何Alamofire的类型：包括参数、返回值、公开属性都不要用DataRequest、AF这类Alamofire独有的类型，所有Alamofire的调用逻辑都封装在internal/private级别的代码中，对外仅暴露你自定义的网络请求、响应类型

方案3：将网络层改为动态Framework（适合模块化程度更高的场景） #

如果静态库的限制较多，可以调整网络层target的类型为动态Framework，这种方案的依赖隔离效果更彻底：

• 在网络层target的Build Settings的Linked Frameworks and Libraries中，将Alamofire的链接状态设置为Do Not Embed
• 只要你保持网络层的公开接口完全不依赖Alamofire的类型，Alamofire只会被链接到网络层内部，不会暴露给上层的主应用和其他模块
• 这种方案的优势是后续如果要替换Alamofire为其他网络库，上层代码完全不需要修改，只要网络层的公开接口保持一致即可

无论用哪种方案，都必须保证网络层的公开接口完全和Alamofire解耦，哪怕你完成了模块隐藏，只要公开接口里用到了Alamofire的类型，上层代码就还是会被迫依赖Alamofire才能编译。

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