Angular中Shared Module（共享模块）的实际作用是什么？

你误解的核心：Shared Module 不是“全量导入容器” #

你遇到的困惑本质是用错了Shared Module的使用方式——它的核心目的不是把所有共享依赖一股脑塞进去让所有模块全量引入，而是做精细化的依赖管理与按需复用，同时解决Angular中组件重复声明的限制。

Shared Module 的真正优势 #

1. 消除重复代码，规避声明冲突 #

Angular禁止在多个模块中重复声明同一个组件、指令或管道。如果每个特性模块单独导入所需的Material组件，你需要在5个模块里重复写MatButtonModule、MatInputModule这类导入语句，冗余代码会非常多。而Shared Module只需要统一导入并导出这些共享依赖一次，所有特性模块只需导入Shared Module就能使用里面的内容，彻底避免重复代码。

2. 统一维护依赖，降低迭代成本 #

如果后续要升级Material版本、替换某个组件库，或者调整共享组件的配置，你只需要修改Shared Module这一处，不用遍历所有特性模块逐个修改，维护效率大幅提升。

3. 配合Tree Shaking 实现按需打包 #

你担心的“全量导入导致冗余代码”是误解：Angular的Tree Shaking机制会自动剔除未被实际使用的代码。只要你在Shared Module里只导入和导出项目中用到的Material组件（而非整个Material库），最终打包时，每个特性模块只会包含自己用到的组件，不会引入冗余代码。

针对你场景的正确用法 #

针对你提到的10个Material组件、5个特性模块各用2个的场景，正确的做法是：

• 创建SharedMaterialModule，仅导入你用到的10个Material组件，然后统一导出它们
• 每个特性模块只需导入SharedMaterialModule，无需单独导入单个Material组件
• 懒加载的特性模块会自动通过Tree Shaking剔除未使用的Material组件，不会增加打包体积

和App/Core Module的本质区别 #

• 如果把所有Material组件放在App Module，这些组件会被打包进主包，即使部分特性模块是懒加载的，主包体积会变大，直接影响首屏加载速度
• 用Shared Module配合懒加载特性模块，每个懒加载模块只会打包自身用到的Material组件，主包体积更小，性能更优

总结 #

Shared Module不是增加项目复杂度的累赘，而是规范依赖管理、减少重复代码、优化打包性能的实用工具，关键是要掌握“按需导入导出”的正确姿势，而非把它当成全量依赖的容器。

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