Angular 以类似于 ES 模块的方式引入了模块封装的概念。 它基本上意味着可声明的类型——组件、指令和管道——只能由在该模块内声明的组件使用。 例如，如果我尝试使用下面的代码在 App 模块的 App 组件内使用 A 模块中的 a-comp：
@Component({ selector: 'my-app', template: ` <h1>Hello {{name}}</h1> <a-comp></a-comp> ` }) export class AppComponent { }
会收到这个错误消息：
Template parse errors: ‘a-comp’ is not a known element
这是因为 App 模块中没有声明 a-comp。 如果我想使用这个组件，我需要导入定义这个组件的模块。解决方案如下：
@NgModule({ imports: [..., AModule] }) export class AppModule { }
这就是封装发挥作用的地方：A 模块必须通过将 a-comp 添加到 exports 数组来将其声明为在其他 module 内可用：
@NgModule({ ... declarations: [AComponent], exports: [AComponent] }) export class AModule { }
大多数 Angular 新手认为 Providers 也有封装，这种想法是错误的。可以在应用程序内的任何位置访问在任何非延迟加载模块中声明的 Providers.
Modules hierarchy
关于 imported modules 的最大困惑是开发人员认为这些被导入的 Modules 在应用运行时维护了一种层次结构，并且假设导入其他模块的模块成为被导入模块的父模块。
然而，事实并非如此。所有模块在编译阶段合并。因此，导入的模块和导入的模块之间没有层次关系。
所需命名空间之一被定义为默认命名空间。 此命名空间的控制标记不需要前缀。
<View> 标签是必需的，在上面的示例中，核心命名空间在第一行定义。 当然开发人员可以定义任何名称。 例如，为了使标签名称更短，还可以使用 c 而不是 core.
