Angular 模块封装的核心机制

在 Angular 框架中，模块封装的概念与 ES 模块的思路高度相似：组件、指令、管道等可声明类型，默认仅在声明它们的模块内部可用。这意味着，如果某个组件在模块 A 中定义，那么其他模块必须显式导入并获取导出权限后，才能使用该组件。

以实际场景为例，若你在 AppModule 的 AppComponent 中直接引用 AModule 定义的 a-comp 组件，代码如下：

@Component({
  selector: 'my-app',
  template: `
      
Hello {{name}}
      
  `
})
export class AppComponent { }

此时 Angular 会立刻抛出错误：

常见错误信息

Template parse errors: 'a-comp' is not a known element

原因在于 AppModule 并未声明 a-comp。解决方案是先将定义 a-comp 的模块导入 AppModule：

@NgModule({
  imports: [..., AModule]
})
export class AppModule { }

然而仅导入还不够——如果 AModule 未将 a-comp 列入 exports 数组，其他模块仍无法使用。因此 AModule 必须显式导出该组件：

@NgModule({
  ...
  declarations: [AComponent],
  exports: [AComponent]
})
export class AModule { }

至此，模块封装的基本逻辑已经清晰。但许多 Angular 新手容易误解 Providers 也具有类似的封装限制——这其实是一个常见的误区。实际情况是：在非延迟加载的模块中声明的 Providers，整个应用的所有地方都可以访问，不存在模块级别的隔离。

模块层次结构的真相

另一个让开发者困惑的问题是“模块层次结构”。许多开发者认为，当在一个模块中 import 另一个模块时，运行时就会形成父子层级关系——被导入的模块自动成为子模块。但真相是：所有模块在编译阶段已经合并到一起，根本不存在运行时层次结构。

换个角度看，这就像在代码中引入一组命名空间。其中一个命名空间会被设为默认，默认命名空间下的标签无需前缀。例如在模板中， 标签是必需的，核心命名空间通常在第一行定义。当然你也可以为其设置短名称（如用 c 代替 core），使标签更简洁。

总结而言，理解 Angular 模块封装只需抓住两点：一是声明类与 exports 的对应关系，二是不要将导入模块视为建立层级。掌握这些关键点后，多数编译报错和运行时困惑都能迎刃而解。