Angular 2+ 模块/组件为何需按需多次导入而非全局一次性引入？

核心设计前提 #

Angular NgModule 的核心设计逻辑是严格的作用域隔离，所有导入、导出规则都围绕这一前提设计，框架不存在任何全局可直接访问的模板资源，所有跨模块的资源引用都必须有显式的导入链路。 #

疑问1：为什么不能在根模块一次性导入所有资源，全局直接使用？ #

如果在AppModule中一次性导入全部项目依赖，虽然能减少本地代码的导入量，但会造成无法规避的工程问题：

• 彻底打破模块边界。所有组件都能随意引用无约束的内部资源，后续做模块化拆分、懒加载时会出现大量隐式依赖，无法定位资源的实际使用位置
• 完全破坏性能优化能力。所有依赖都打进根模块的首屏bundle，不管用户访问哪个路由都要加载全量代码，首屏体积会随功能增长持续膨胀
• 依赖关系完全失控。没有模块边界约束的跨模块引用会形成网状依赖，后续修改公共组件时可能触发无关联的业务模块报错
• 补充说明：只有通过providedIn: 'root'声明的服务是全局可注入的，组件、指令、管道这类模板类资源，必须在使用它的模块中显式导入对应模块，不存在全局模板可用的情况。

疑问2：通过exports导出的元素是否全局公开可见？ #

这个认知存在明显偏差。exports的可见范围仅覆盖导入了当前模块的下游模块，不属于全局作用域：

• 比如SharedModule导出了SpinnerComponent，只有在自身imports数组中显式声明导入了SharedModule的模块，才能在模板中使用这个组件
• 哪怕SharedModule被AppModule导入，独立的懒加载业务模块因为和根模块存在作用域隔离，没有单独导入SharedModule的话，依然无法使用它导出的资源
• 结合你贴的代码看：项目的SharedModule虽然在imports中引入了大量Material组件模块，但并没有把这些模块加到exports列表中，下游模块哪怕导入了SharedModule，也无法直接使用这些Material组件，这是重复导入的核心诱因之一。

疑问3：如果重复导入是框架强制要求，为什么不直接在业务模块按需导入，反而要在全局模块集中导入？ #

这种集中导入和按需导入的分工，本质是按模块加载链路做的合理拆分：

• 集中导入在根模块的资源，一般是根链路下所有预加载模块都需要使用的公共依赖，比如HttpClientModule、BrowserAnimationsModule、全局布局组件，这些资源本来就会随根模块加载，不需要每个业务模块重复声明
• 你观察到的业务模块重复导入的场景，通常分为两类：
  1. 历史代码遗留：早期团队没有把公共依赖统一在SharedModule中正确导出，业务模块用什么就自己导什么，属于代码规范缺失，不是框架的强制要求
  2. 懒加载模块的独立依赖：懒加载模块和根模块是完全隔离的作用域，就算根模块已经导入过某个依赖，懒加载模块要使用的话必须单独导入一遍，这是框架的强制规则，不属于无意义的重复劳动。

内容的提问来源于stack exchange，提问作者Aldemar Cuartas Carvajal