` element that displayed the `ContactComponent` is gone; you're routing to the _Contact_ page now.
The root AppModule
The `AppModule` is slimmer now.
这下 `AppModule` 苗条多了。
The `AppModule` is no longer aware of the application domains such as contacts, heroes, and crises.
Those concerns are pushed down to `ContactModule`, `HeroesModule`, and `CrisisModule` respectively
and only the routing configuration knows about them.
The significant change from version 2 is the addition of the *AppRoutingModule* to the NgModule `imports`.
The `AppRoutingModule` is a [routing module](guide/router#routing-module)
that handles the app's routing concerns.
与第二版相比，最值得注意的修改是`imports`中那个额外的***AppRoutingModule***模块。
`AppRoutingModule`是一个[**路由模块**](guide/router#routing-module)
用来处理应用的路由。
### _AppRoutingModule_
The router is the subject of the [Routing & Navigation](guide/router) guide, so this section skips many routing details and
concentrates on the _intersection_ of NgModules and routing.
You can specify router configuration directly within the root `AppModule` or within a feature module.
The _Router guide_ recommends instead that you locate router configuration in separate, dedicated NgModules, called _routing modules_.
You then import those routing modules into their corresponding root or feature modules.
The goal is to separate the normal declarative concerns of an NgModule from the often complex router configuration logic.
By convention, a routing module's name ends in `...RoutingModule`.
The top-level root module is `AppModule` and it imports its companion _routing module_ called `AppRoutingModule`.
Here is this app's `AppRoutingModule`, followed by a discussion.
### 应用路由
The `AppRoutingModule` defines three routes:
The first route redirects the empty URL (such as `http://host.com/`)
to another route whose path is `contact` (such as `http://host.com/contact`).
第一个路由把空白 URL（例如`http://host.com/`）重定向到了另一个路径为`contact`的路由（例如`http://host.com/contact`）。
The `contact` route isn't defined within the `AppRoutingModule`.
It's defined in the _Contact_ feature's _own_ routing module, `ContactRoutingModule`.
`contact`路由并不是在`AppRoutingModule`中定义的，而是定义在*联系人*特性区自己的路由模块`ContactRoutingModule`中。
It's standard practice for feature modules with routing components to define their own routes.
You'll get to [`ContactRoutingModule`](#contact-routing-module) in a moment.
对于带有路由组件的特性模块，标准做法就是让它们定义自己的路由。
稍后我们就会在 [`ContactRoutingModule`](#contact-routing-module) 中看到这些。
The remaining two routes use lazy loading syntax to tell the router where to find the modules for the hero and crisis features:
另外两个路由使用惰性加载语法来告诉路由器要到哪里去找英雄特性模块和危机特性模块。
A lazy-loaded NgModule location is a _string_, not a _type_.
In this app, the string identifies both the NgModule _file_ and the NgModule _class_,
the latter separated from the former by a `#`.
惰性加载模块的位置是*字符串*而不是*类型*。
在本应用中，该字符串同时标记出了模块*文件*和模块*类*，两者用`#`分隔开。
### Routing module imports
A _routing module_ typically imports the Angular `RouterModule` so it can register routes.
It may also import a _feature module_ which registers routes (either directly or through its companion _routing module_).
This `AppRoutingModule` does both.
It first imports the `ContactModule`, which [as you'll see](#contact-routing-module),
imports its own `ContactRoutingModule`.
**Import order matters!**
Because "contacts" is the first defined route and the default route for the app,
you must import it _before_ all other routing-related modules.
The second import registers the routes defined in this module
by calling the `RouterModule.forRoot` class method.
The `forRoot` method does two things:
1. Configures the router with the supplied _routes_.
1. Initializes the Angular router itself.
Call `RouterModule.forRoot` exactly once for the entire app.
Calling it in the `AppRoutingModule`, the companion to the root `AppModule`,
is a good way to ensure that this method is called exactly once.
Never call `RouterModule.forRoot` in a feature's _routing module_.
永远不要在特性路由模块中调用`RouterModule.forRoot`！
### Re-export _RouterModule_
All _routing modules_ should re-export the `RouterModule`.
Re-exporting `RouterModule` makes the router directives
available to the companion module that imports it.
This is a considerable convenience for the importing module.
For example, the `AppComponent` template relies on the
[`routerLink`](guide/router#router-links) directive
to turn the user's clicks into navigations.
The Angular compiler only recognizes `routerLink` because
- `AppComponent`is declared by `AppModule`,
- `AppModule` imports `AppRoutingModule`,
- `AppRoutingModule` exports `RouterModule`, and
- `RouterModule` exports the `RouterLink` directive.
If `AppRoutingModule` didn't re-export `RouterModule`, the `AppModule` would have to import the `RouterModule` itself.
{@a contact-routing-module}
### Routing to a feature module
### 路由到特性模块
The three feature modules (`ContactModule`, `HeroModule`, `CrisisModule`)
have correspondingroutingmodules (`ContactRoutingModule`, `HeroRoutingModule`, `CrisisRoutingModule`).
They follow the same pattern as the `AppRoutingModule`.
* define routes
* register the routes with Angular's `RouterModule`
* export the `RouterModule`.
The `ContactRoutingModule` is the simplest of the three.
It defines and registers a single route to the `ContactComponent`.
There is **one critical difference** from `AppRoutingModule`:
you pass the routes to `RouterModule.forChild`, not `forRoot`.
Always call `RouterModule.forChild` in a feature-routing module.
Never call `RouterModule.forRoot`.
总是在特性路由模块中调用`RouterModule.forChild`。
永远不要调用`RouterModule.forRoot`。
#### _ContactModule_ changes
Because the app navigates to the `ContactComponent` instead of
simply displaying it in the `AppComponent` template,
the `ContactModule` has changed.
* It imports the `ContactRoutingModule`.
* It no longer exports `ContactComponent`.
The `ContactComponent` is only displayed by the router,
No template references its `` selector.
There's no reason to make it public via the `exports` array.
Here is the latest version, side-by-side with the previous version.
`ContactModule`已经做了两个微小但重要的细节改动：
{@a hero-module}
### Lazy-loaded routing
The `HeroModule` and `CrisisModule` have corresponding _routing modules_, `HeroRoutingModule` and `CrisisRoutingModule`.
The app _lazy loads_ the `HeroModule` and the `CrisisModule`.
That means the `HeroModule` and the `CrisisModule` are not loaded into the browser until the user navigates to their components.
Do not import the `HeroModule` or `CrisisModule` or any of their classes outside of their respective file folders.
If you do, you will unintentionally load those modules and all of their code
when the application starts, defeating the purpose of lazy loading.
For example, if you import the `HeroService` in `AppModule`,
the `HeroService` class and all related hero classes will be loaded when the application starts.
Lazy loading can improve the app's perceived performance because the browser doesn't have to process lazy-loaded code when the app starts.
It may _never_ process that code.
You cannot tell that these modules are lazy-loaded by looking at their _routing modules_.
They happen to be a little more complex than `ContactRoutingModule`.
For example, The `HeroRoutingModule` has [child routes](guide/router#child-routing-component).
But the added complexity springs from intrinsic hero and crisis functionality, not from lazy loading.
Fundamentally, these _routing modules_ are just like `ContactRoutingModule` and you write them the same way.
{@a lazy-load-DI}
### Lazy-loaded NgModule providers
There is a **runtime difference** that can be significant.
Services provided by lazy-loaded NgModules are only available to classes instantiated within the lazy-loaded context. The reason has to do with dependency injection.
When an NgModule is _eagerly loaded_ as the application starts,
its providers are added to the application's _root injector_.
Any class in the application can inject a service from the _root injector_.
When the router _lazy loads_ an NgModule, Angular instantiates the module
with a _child injector_ (a descendant of the _root injector_)
and adds the module's providers to this _child injector_.
Classes created with the _child injector_ can inject one of its provided services.
Classes created with _root injector_ cannot.
Each of the three feature modules has its own data access service.
Because the `ContactModule` is _eagerly loaded_ when the application starts,
its `ContactService` is provided by the application's _root dependency injector_.
That means the `ContactService` can be injected into any application class, including hero and crisis components.
Because `CrisisModule` is _lazy-loaded_,
its `CrisisService` is provided by the `CrisisModule` _child injector_.
It can only be injected into one of the crisis components.
No other kind of component can inject the `CrisisService` because no other kind of component can be reached along a route that lazy loads the `CrisisModule`.
### Lazy-loaded NgModule lifetime
Both eager and lazy-loaded NgModules are created _once_ and never destroyed.
This means that their provided service instances are created _once_ and never destroyed.
As you navigate among the application components, the router creates and destroys instances of the contact, hero, and crisis components.
When these components inject data services provided by their modules,
they get the same data service instance each time.
If the `HeroService` kept a cache of unsaved changes and the user navigated to the `ContactComponent` or the `CrisisListComponent`, the pending hero changes would remain in the one `HeroService` instance, waiting to be saved.
But if you provided the `HeroService` in the `HeroComponent` instead of the `HeroModule`, new `HeroService` instances would be created each time
the user navigated to a hero component. Previously pending hero changes would be lost.
To illustrate this point, the sample app provides the `HeroService` in the `HeroComponent` rather than the `HeroModule`.
Run the app, open the browser development tools, and look at the console as you navigate among the feature pages.
// App starts
ContactService instance created.
...
// Navigate to Crisis Center
CrisisService instance created.
...
// Navigate to Heroes
HeroService instance created.
...
// Navigate to Contact
HeroService instance destroyed.
...
// Navigate back to Heroes
HeroService instance created.
The console log shows the `HeroService` repeatedly created and destroyed.
The `ContactService` and `CrisisService` are created but never destroyed, no matter where you navigate.
#### Run it
Try this routed version of the sample.
试试在线例子。
{@a shared-module}
## Shared modules
## 共享模块
The app is shaping up.
But there are a few annoying problems.
There are three unnecessarily different _highlight directives_
and the many files cluttering the app folder level could be better organized.
本应用在继续演进中。
让我们感到不爽的是：这里有`HighlightDirective`的三个不同版本。
还有一大堆其它乱七八糟的东西堆在 app 目录这一级，我们得把它们清出去。
You can eliminate the duplication and tidy-up by writing a `SharedModule`
to hold the common components, directives, and pipes.
Then share this NgModule with the other NgModules that need these declarables.
Use the CLI to create the `SharedModule` class in its `src/app/shared` folder.
ng generate module shared
Now refactor as follows:
- Move the `AwesomePipe` from `src/app/contact` to `src/app/shared`.
把 `AwesomePipe` 和 `HighlightDirective` 从 `src/app/contact` 移到 `src/app/shared` 中。
- Move the `HighlightDirective` from `src/app/hero` to `src/app/shared`.
把 `HighlightDirective` 从 `src/app/hero` 移到 `src/app/shared` 中。
- Delete the _highlight directive_ classes from `src/app/` and `src/app/contact`.
从 `src/app/` 和 `src/app/contact` 删除*高亮指令*类。
- Update the `SharedModule` as follows:
把 `SharedModule` 改成这样：
Note the following:
值得注意的有：
* It declares and exports the shared pipe and directive.
它导入了`CommonModule`，这是因为它的组件需要这些公共指令。
* It imports and re-exports the `CommonModule` and `FormsModule`
* It can re-export `FormsModule` without importing it.
### Re-exporting NgModules
Technically, there is no need for `SharedModule` to import `CommonModule` or `FormsModule`.
`SharedModule` doesn't declare anything that needs material from `CommonModule` or `FormsModule`.
But NgModules that would like to import `SharedModule` for its pipe and highlight directive happen also to declare components that need `NgIf` and `NgFor` from `CommonModule`
and do two-way binding with `[(ngModel)]` from the `FormsModule`.
Normally, they'd have to import `CommonModule` and `FormsModule` as well as `SharedModule`.
正如我们所期待的，它声明并导出了工具性的管道、指令和组件类。
Now they can just import `SharedModule`.
By exporting `CommonModule` and `FormsModule`,
`SharedModule` makes them available to its importers _for free_.
#### A trimmer _ContactModule_
See how `ContactModule` became more concise, compared to its previous version:
Notice the following:
* The `AwesomePipe` and `ContactHighlightDirective` are gone.
* The imports include `SharedModule` instead of `CommonModule` and `FormsModule`.
* The new version is leaner and cleaner.
### Why _TitleComponent_ isn't shared
### 为什么 *TitleComponent* 没有被共享
`SharedModule` exists to make commonly used components, directives, and pipes available
for use in the templates of components in many other NgModules.
设计`SharedModule`的目的在于让常用的组件、指令和管道可以被用在*很多*其它模块的组件模板中。
The `TitleComponent` is used only once by the `AppComponent`.
There's no point in sharing it.
而`TitleComponent`*只被*`AppComponent`用了一次，因此没必要共享它。
{@a no-shared-module-providers}
### Why _UserService_ isn't shared
### 为什么 *UserService* 没有被共享
While many components share the same service instances,
they rely on Angular dependency injection to do this kind of sharing, not the NgModule system.
虽然很多组件都共享着同一个服务*实例*，但它们是靠 Angular 的依赖注入体系实现的，而不是模块体系。
Several components of the sample inject the `UserService`.
There should be only one instance of the `UserService` in the entire application
and only one provider of it.
例子中的很多组件都注入了`UserService`。
在整个应用程序中，*只应该有一个*`UserService`的实例，并且它*只应该有一个*提供商。
`UserService` is an application-wide singleton.
You don't want each NgModule to have its own separate instance.
Yet there is [a real danger](guide/ngmodule-faq#q-why-bad) of that happening
if the `SharedModule` provides the `UserService`.
`UserService`是全应用级单例。
我们不希望每个模块都各自有它的实例。
而如果由`SharedModule`提供`UserService`，就会导致[铁板钉钉的危险](guide/ngmodule-faq#q-why-bad)。
Do *not* specify app-wide singleton `providers` in a shared module.
A lazy-loaded NgModule that imports that shared module makes its own copy of the service.
**不要**在共享模块中把应用级单例添加到`providers`中。
否则如果一个惰性加载模块导入了此共享模块，就会导致它自己也生成一份此服务的实例。
{@a core-module}
## The Core module
## 核心 (Core) 模块
At the moment, the root folder is cluttered with the `UserService`
and `TitleComponent` that only appear in the root `AppComponent`.
You didn't include them in the `SharedModule` for reasons just explained.
现在，我们的根目录下只剩下`UserService`和`TitleComponent`这两个被根组件`AppComponent`用到的类没有清理了。
但正如我们已经解释过的，它们无法被包含在`SharedModule`中。
Instead, gather them in a single `CoreModule` that you import once when the app starts
and never import anywhere else.
不过，我们可以把它们收集到单独的`CoreModule`中，并且**只在应用启动时导入它*一次***，**而不会在其它地方导入它**。
Perform the following steps:
1. Create a `CoreModule` class in an `src/app/core` folder.
在 `src/app/core` 目录下创建 `CoreModule` 类。
1. Move the `TitleComponent` and `UserService` from `src/app/` to `src/app/core`.
把 `TitleComponent` 和 `UserService` 从 `src/app/` 移到 `src/app/core`。
1. Declare and export the `TitleComponent`.
声明并导出 `TitleComponent` 。
1. Provide the `UserService`.
提供 `UserService`。
1. Update the root `AppModule` to import `CoreModule`.
修改 `AppModule` 根模块，使其导入 `CoreModule`。
Most of this work is familiar. The interesting part is the `CoreModule`.
这些都是一些熟悉的普通任务。令人感兴趣的是`CoreModule`：
You're importing some extra symbols from the Angular core library that you're not using yet.
They'll become relevant later in this page.
我们正在从 Angular 核心库中导入一些从未用到的符号，稍后我们会接触它们。
The `@NgModule` metadata should be familiar.
You declare the `TitleComponent` because this NgModule owns it.
You export it because `AppComponent` (which is in `AppModule`) displays the title in its template.
`TitleComponent` needs the Angular `NgIf` directive that you import from `CommonModule`.
我们对`@NgModule`的元数据应该很熟悉。
由于该模块_拥有_`TitleComponent`，所以我们声明了它。由于`AppComponent`（位于`AppModule`模块）在模板中显示了这个标题，所以我们导出了它。
由于`TitleComponent`需要用到 Angular 的`NgIf`指令，所以我们导入了`CommonModule`。
`CoreModule` provides the `UserService`. Angular registers that provider with the app root injector,
making a singleton instance of the `UserService` available to any component that needs it,
whether that component is eagerly or lazily loaded.
`CoreModule`_提供_了`UserService`。Angular 在该应用的根注入器中注册了它的提供商，
导致这份`UserService`的实例在每个需要它的组件中都是可用的，无论那个组件时主动加载的还是惰性加载的。
Why bother?
没必要？
This scenario is clearly contrived.
The app is too small to worry about a single service file and a tiny, one-time component.
这个场景设计的是有点生硬。
该应用太小了，所以其实并不需要拆分出单独的服务文件和小型的、一次性的组件。
A `TitleComponent` sitting in the root folder isn't bothering anyone.
The root `AppModule` can register the `UserService` itself,
as it does currently, even if you decide to relocate the `UserService` file to the `src/app/core` folder.
把`TitleComponent`放在根目录中其实也无所谓。
即使我们决定把`UserService`文件挪到`app/core`目录中，根`AppModule`也仍然可以自己注册`UserService`（就像现在这样）。
Real-world apps have more to worry about.
They can have several single-use components (such as spinners, message toasts, and modal dialogs)
that appear only in the `AppComponent` template.
You don't import them elsewhere so they're not shared in that sense.
Yet they're too big and messy to leave loose in the root folder.
但真实的应用要考虑很多。
它们有一些只用于`AppComponent`的模板的一次性的组件（例如：加载动画、消息浮层和模态对话框等）。
我们不用在其它地方导入它们，因此没必要*共享*它们。
然而如果把它们留在根目录，还是显得太大、太乱了。
Apps often have many singleton services like this sample's `UserService`.
Each must be registered exactly once, in the app root injector, when the application starts.
应用通常还有很多像这里的`UserService`这样的单例服务。
当程序启动时，每个服务都只能在应用的“根注入器”中*注册一次*。
While many components inject such services in their constructors—and
therefore require JavaScript `import` statements to import their symbols—no
other component or NgModule should define or re-create the services themselves.
Their _providers_ aren't shared.
当很多组件在它们的构造函数中注入这些服务时 —
因此也需要用 JavaScript 的`import`语句来导入它们的符号 —
任何组件或模块自身都不应该定义或重新创建这些服务。
因为它们的*提供商*不是共享的。
We recommend collecting such single-use classes and hiding their details inside a `CoreModule`.
A simplified root `AppModule` imports `CoreModule` in its capacity as orchestrator of the application as a whole.
因此我们建议把这些一次性的类收集到`CoreModule`中，并且隐藏它们的实现细节。
简化之后的根模块`AppModule`导入`CoreModule`来获取其能力。记住，根模块是整个应用的总指挥，不应该插手过多细节。
#### A trimmer _AppModule_
#### 清理 *AppModule*
Here is the updated `AppModule` paired with version 3 for comparison:
这里是更新后的`AppModule`与其第三版本的对比：
`AppModule` now has the following qualities:
`AppModule`现在变得：
* A little smaller because many `src/app/root` classes have moved to other NgModules.
更小了。因为很多`src/app/root`下的类被移到了其它模块。
* Stable because you'll add future components and providers to other NgModules, not this one.
更稳定了。因为我们以后会在其它模块中添加组件和服务提供商，而不是这里。
* Delegated to imported NgModules rather than doing work.
导入其它模块并把任务委托给它们，而不是亲力亲为。
* Focused on its main task, orchestrating the app as a whole.
聚焦于自己的主要任务：总指挥整个应用程序。
{@a core-for-root}
### Configure core services with _CoreModule.forRoot_
### 用 *CoreModule.forRoot* 配置核心服务
An NgModule that adds providers to the application can offer a facility for configuring those providers as well.
为应用添加服务提供商的模块也可以同时提供配置那些提供商的功能。
By convention, the `forRoot` static method both provides and configures services at the same time.
It takes a service configuration object and returns a
[ModuleWithProviders](api/core/ModuleWithProviders), which is
a simple object with the following properties:
按照惯例，模块的静态方法***forRoot***可以同时提供并配置服务。
它接收一个服务配置对象，并返回一个[ModuleWithProviders](api/core/ModuleWithProviders)。这个简单对象具有两个属性：
* `ngModule`: the `CoreModule` class
`ngModule` - `CoreModule`类
* `providers`: the configured providers
`providers` - 配置好的服务提供商
The root `AppModule` imports the `CoreModule` and adds the `providers` to the `AppModule` providers.
根模块`AppModule`会导入`CoreModule`类并把它的`providers`添加到`AppModule`的服务提供商中。
More precisely, Angular accumulates all imported providers before appending the items listed in `@NgModule.providers`.
This sequence ensures that whatever you add explicitly to the `AppModule` providers takes precedence
over the providers of imported NgModules.
更精确的说法是，Angular 会先累加所有导入的提供商，*然后才*把它们追加到`@NgModule.providers`中。
这样可以确保我们显式添加到`AppModule`中的那些提供商总是优先于从其它模块中导入的提供商。
Add a `CoreModule.forRoot` method that configures the core `UserService`.
现在添加`CoreModule.forRoot`方法，以便配置核心中的`UserService`。
You've extended the core `UserService` with an optional, injected `UserServiceConfig`.
If a `UserServiceConfig` exists, the `UserService` sets the user name from that config.
我们曾经用一个可选的、被注入的`UserServiceConfig`服务扩展过核心的`UserService`服务。
如果有`UserServiceConfig`，`UserService`就会据此设置用户名。
Here's `CoreModule.forRoot` that takes a `UserServiceConfig` object:
这里的`CoreModule.forRoot`接收`UserServiceConfig`对象：
Lastly, call it within the `imports` list of the `AppModule`.
最后，我们在`AppModule`的`imports`*列表*中调用它。
The app displays "Miss Marple" as the user instead of the default "Sherlock Holmes".
该应用不再显示默认的 “Sherlock Holmes”，而是用 “Miss Marple” 作为用户名称。
Call `forRoot` only in the root module, `AppModule`.
Calling it in any other NgModule, particularly in a lazy-loaded NgModule,
is contrary to the intent and can produce a runtime error.
只在应用的根模块`AppModule`中调用`forRoot`。
如果在其它模块（特别是惰性加载模块）中调用它则违反了设计意图，并会导致运行时错误。
Remember to _import_ the result; don't add it to any other `@NgModule` list.
别忘了_导入_其返回结果，而且不要把它添加到`@NgModule`的其它任何列表中。
{@a prevent-reimport}
### Prevent reimport of the _CoreModule_
## 禁止多次导入*CoreModule*
Only the root `AppModule` should import the `CoreModule`.
[Bad things happen](guide/ngmodule-faq#q-why-bad) if a lazy-loaded NgModule imports it.
只有根模块`AppModule`才能导入`CoreModule`。
如果惰性加载模块导入了它，就会[出问题](guide/ngmodule-faq#q-why-bad)。
You could hope that no developer makes that mistake.
Or you can guard against it and fail fast by adding the following `CoreModule` constructor.
我们可以*祈祷*任何开发人员都不会犯错。
但是最好还是对它进行一些保护，以便让它“尽快出错”。只要把下列代码添加到`CoreModule`的构造函数中就可以了。
The constructor tells Angular to inject the `CoreModule` into itself.
That seems dangerously circular.
这个构造函数会要求 Angular 把`CoreModule`注入自身。这看起来像一个危险的循环注入。
The injection would be circular if Angular looked for `CoreModule` in the _current_ injector.
The `@SkipSelf` decorator means "look for `CoreModule` in an ancestor injector, above me in the injector hierarchy."
确实，如果 Angular 在*当前*注入器中查阅`CoreModule`，这确实会是一个循环引用。
不过，`@SkipSelf`装饰器意味着“在当前注入器的所有祖先注入器中寻找`CoreModule`。”
If the constructor executes as intended in the `AppModule`,
there is no ancestor injector that could provide an instance of `CoreModule`.
The injector should give up.
如果该构造函数在我们所期望的`AppModule`中运行，就没有任何祖先注入器能够提供`CoreModule`的实例，于是注入器会放弃查找。
By default, the injector throws an error when it can't find a requested provider.
The `@Optional` decorator means not finding the service is OK.
The injector returns `null`, the `parentModule` parameter is null,
and the constructor concludes uneventfully.
默认情况下，当注入器找不到想找的提供商时，会抛出一个错误。
但`@Optional`装饰器表示找不到该服务也无所谓。
于是注入器会返回`null`，`parentModule`参数也就被赋成了空值，而构造函数没有任何异常。
It's a different story if you improperly import `CoreModule` into a lazy-loaded NgModule such as `HeroModule` (try it).
如果我们错误的把`CoreModule`导入了一个惰性加载模块（例如`HeroModule`）中，那就不一样了。
Angular creates a lazy-loaded NgModule with its own injector, a _child_ of the root injector.
`@SkipSelf` causes Angular to look for a `CoreModule` in the parent injector, which this time is the root injector.
Of course it finds the instance imported by the root `AppModule`.
Now `parentModule` exists and the constructor throws the error.
Angular 创建一个惰性加载模块，它具有自己的注入器，它是根注入器的*子注入器*。
`@SkipSelf`让 Angular 在其父注入器中查找`CoreModule`，这次，它的父注入器却是根注入器了（而上次父注入器是空）。
当然，这次它找到了由根模块`AppModule`导入的实例。
该构造函数检测到存在`parentModule`，于是抛出一个错误。
## Conclusion
## 总结
You made it! You can examine and download the complete source for this final version from the live example.
完工！你可以到下面的在线例子中试验它，并下载最终版本的全部源码。
## Frequently asked questions
## 常见问题 (FAQ)
Now that you understand NgModules, you may be interested
in the companion [NgModule FAQs](guide/ngmodule-faq "NgModule FAQs") page
with its ready answers to specific design and implementation questions.
现在，你已经理解了 Angular 的模块。可能你还会对烹饪宝典中的
[Angular 模块常见问题](guide/ngmodule-faq "Angular 模块常见问题")感兴趣，
它解答了很多关于设计和实现方面的问题。