Angular通用模块导入方案选择：SharedModule还是多模块导入？

兄弟，你这个问题绝对是Angular模块化重构里的高频疑问，我来给你把两种方案的利弊说透，帮你做最优选择。

先看方案1：用SharedModule统一导入导出通用模块 #

这绝对是Angular社区公认的最佳实践，优势拉满：

• 彻底减少重复代码：不用在每个子模块里都写imports: [CommonModule, FormsModule]这种重复代码，只需要在SharedModule里导入并导出这些通用模块，其他业务模块只要导入SharedModule就能直接用所有通用功能，写代码爽多了
• 维护成本极低：以后要加新的通用模块（比如ReactiveFormsModule）或者移除某个模块，只需要改SharedModule这一个地方，所有依赖的子模块自动生效，完全不用担心漏改某个模块
• 符合模块化设计初衷：SharedModule就是用来做“通用工具包”的，把所有全局常用的无服务依赖的模块聚合在一起，给其他模块提供统一入口

⚠️ 这里要注意一个坑：别把带providers的模块（比如HttpClientModule）放到SharedModule里导出！因为如果SharedModule被多个懒加载模块导入，会导致服务被多次实例化，破坏单例模式。这类模块应该放到CoreModule里，并且确保CoreModule只在AppModule里导入一次。

再看方案2：每个子模块单独导入通用模块 #

这种方案几乎没什么优点，全是槽点：

• 重复劳动到崩溃：项目模块少的时候还好，模块一多，每个都要手动加一遍通用模块的导入，简直是体力活，还容易漏写
• 维护起来头大：以后要调整通用模块的话，得挨个模块去修改，极容易出错，万一漏改某个模块，就会出现奇怪的报错
• 违背模块化复用思想：我们搞模块化就是为了减少冗余、提升复用性，这种方式反而把代码拆得更散，完全没必要

结论：果断选方案1 #

用SharedModule来统一管理和导出CommonModule、FormsModule这类无服务依赖的通用模块，是Angular项目模块化的标准操作，既提升开发效率，又能避免后期的维护噩梦。只要注意区分通用模块的类型（有无providers），把带服务的模块放到CoreModule单独处理，就完美解决问题了。

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