Flutter Clean架构下网络与第三方SDK管理疑问求助

问题1：API Client的封装与多Feature共用处理 #

• 必须封装全局API Client，但要调整返回逻辑：保留Client的通用请求能力（比如统一baseUrl、拦截器、全局错误处理），但不要直接返回特定模型，改为返回原始响应数据（如Map<String, dynamic>或Response对象）。模型转换的逻辑下放到对应Feature的Data层，完全符合Clean架构中Data层负责数据映射的要求。
• 无需在各Feature的Data层单独实现Client：重复实现会大幅增加维护成本，全局封装的Client作为跨Feature的基础设施服务复用即可。
• 不建议在features目录下建common模块：通用基础设施服务要和业务Feature解耦，直接将API Client放在infrastructure层，通过get_it等依赖注入工具提供给各Feature的Data层使用。features目录应专注于业务模块，避免混入通用服务。

问题2：第三方库的封装与存放位置 #

• 第三方库必须封装：这是Clean架构隔离外部依赖的核心要求，能避免业务逻辑直接绑定具体的第三方实现，后续替换或升级库时不会影响上层代码。比如对shared_preferences封装成LocalStorageService，对dio封装成全局API Client。
• 封装类放在infrastructure层是正确选择：该层的定位就是存放跨Feature的通用基础设施服务，包括API Client、第三方库封装、通用工具等，和core、features同级的分层方式完全合理。
• infrastructure层的组织方式：无需当作无Presentation层的Feature处理，建议按服务类型划分目录：
  • infrastructure/api：全局API Client、拦截器、通用网络配置
  • infrastructure/storage：本地存储封装类（如SharedPreferences、Hive）
  • infrastructure/logger：日志工具封装
  • infrastructure/di：依赖注入配置（get_it的注册逻辑）
    每个封装类都要提供抽象接口，上层Data层依赖抽象而非具体实现，进一步强化依赖倒置原则。

内容的提问来源于stack exchange，提问作者张黒猫