Angular共享模块与单组件模块架构选型最佳实践

两种方案不存在互斥的对错关系，也没有覆盖所有场景的唯一最佳实践，二者适配的项目阶段、团队规模差异很大，完全可以结合使用：

• 方案a：SharedModule统一管理跨模块复用组件、指令、管道
  这是官方风格指南面向常规业务项目给出的标准方案，最大的优势是开发维护成本低：所有公共复用单元收敛在同一个模块下，业务特性模块只要单次导入SharedModule就能拿到所有公共依赖，不用每次用公共组件都翻找对应模块，适合团队规模小、迭代节奏快、体量在中等及以下的业务项目，尤其是内部中后台类项目。
  用这个方案要注意几个避坑点：不要在SharedModule里注册全局单例服务，不要把仅在1-2个特性模块里用到的非通用组件塞进共享模块造成冗余，懒加载场景下要注意模块导入方式避免公共代码被重复打包。
• 方案b：单个组件/指令/管道对应独立模块
  这是通用组件库、超大型项目适用的设计思路，和Angular v14推出的standalone component设计逻辑完全一致：每个公共能力单元做独立模块封装，消费方可以按需导入实际用到的单元，摇树优化效率最高，能最大程度控制打包体积。Angular Material作为面向全场景的通用组件库，必须做这种细粒度拆分，才能避免出现“用了一个按钮就把整套组件库打进包”的体积浪费问题。
  这个方案的缺点是开发维护成本更高：开发时每次使用公共组件都要手动导入对应模块，会增加一定的重复工作量，如果是小团队做小体量项目，一上来就做这种细粒度拆分属于典型的过度设计。

实际落地不需要二选一，完全可以组合使用：

1. 底层公共组件、指令、管道先按细粒度做独立封装，保证每个单元可以单独被导入，不强制绑定在共享模块上
2. 把项目里80%场景都会用到的高频公共单元，统一汇总导出到一个轻量SharedModule里，日常业务开发直接导入这个模块拿高频依赖，低频使用的特殊公共单元再按需单独导入对应模块
3. 如果项目已经升级到支持standalone component的Angular版本，可以直接用独立组件替代单组件模块的封装，本质就是方案b的官方简化实现，连给单个组件建模块的步骤都能省掉，按需导入即可。

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