anchor.diff:    在不同层次上重新配置一个或多个提供商的能力，开启了一些既有趣又有用的可能性。
   
     ### Scenario: service isolation
  +  
  +  ### 场景：服务隔离
   
     Architectural reasons may lead you to restrict access to a service to the application domain where it belongs.
  +  
  +  出于架构方面的考虑，可能会让你决定把一个服务限制到只能在它所属的特定领域中访问。
   
     The guide sample includes a `VillainsListComponent` that displays a list of villains.
     It gets those villains from a `VillainsService`.
  +  
  +  本章的范例中包括一个`VillainsListComponent`，它显示一个反派的列表。
   
     While you _could_ provide `VillainsService` in the root `AppModule` (that's where you'll find the `HeroesService`),
     that would make the `VillainsService` available everywhere in the application, including the _Hero_ workflows.
  +  
  +  虽然我们也可以在根模块`AppModule`中提供`VillainsService`（就像`HeroesService`那样），不过那样一来就会导致在整个应用中到处都能访问到`VillainsService`，包括在*英雄*工作流中。
   
     If you later modified the `VillainsService`, you could break something in a hero component somewhere.
     That's not supposed to happen but providing the service in the root `AppModule` creates that risk.
  +  
  +  如果我们以后修改了`VillainsService`，那就可能会破坏英雄组件中的某些部分。
  +  这可不妙，但是在根模块`AppModule`中提供这个服务可能会导致这种风险。
   
     Instead, provide the `VillainsService` in the `providers` metadata of the `VillainsListComponent` like this:
  +  
  +  我们可以换一种方案：在`VillainsListComponent`元数据的`providers`中提供`VillainsService`，就像这样：
   
   +makeExcerpt('src/app/villains-list.component.ts (metadata)')
   
  
positive.code:   By providing `VillainsService` in the `VillainsListComponent` metadata and nowhere else,
    the service becomes available only in the `VillainsListComponent` and its sub-component tree.
    It's still a singleton, but it's a singleton that exist solely in the _villain_ domain.
  
    Now you know that a hero component can't access it. You've reduced your exposure to error.
  
    ### Scenario: multiple edit sessions
  
    Many applications allow users to work on several open tasks at the same time.
    For example, in a tax preparation application, the preparer could be working on several tax returns,
    switching from one to the other throughout the day.
  
    This guide demonstrates that scenario with an example in the Tour of Heroes theme.
    Imagine an outer `HeroListComponent` that displays a list of super heroes.
  
    To open a hero's tax return, the preparer clicks on a hero name, which opens a component for editing that return.
    Each selected hero tax return opens in its own component and multiple returns can be open at the same time.
  
    Each tax return component has the following characteristics:
  
    * Is its own tax return editing session.
    * Can change a tax return without affecting a return in another component.
    * Has the ability to save the changes to its tax return or cancel them.
  
  figure.image-display
    img(src="/resources/images/devguide/dependency-injection/hid-heroes-anim.gif" width="400" alt="Heroes in action")
  
negative.code:     
  :marked
    ### Re-providing a service at different levels
    
    ### 在不同层级再次提供同一个服务
  
    You can re-register a provider for a particular dependency token at multiple levels of the injector tree.
    You don't *have* to re-register providers. You shouldn't do so unless you have a good reason.
    But you *can*.
    
    我们可以在注入器树中的多个层次上为指定的依赖令牌重新注册提供商。
    但*并非必须*重新注册，事实上，虽然可以重新注册，但除非有很好的理由，否则不应该这么做。
  
    As the resolution logic works upwards, the first provider encountered wins.
    Thus, a provider in an intermediate injector intercepts a request for a service from something lower in the tree.
    It effectively "reconfigures" and "shadows" a provider at a higher level in the tree.
    
    服务解析逻辑会自下而上查找，碰到的第一个提供商会胜出。
    因此，注入器树中间层注入器上的提供商，可以拦截来自底层的对特定服务的请求。
    这导致它可以"重新配置"和者说"遮蔽"高层的注入器。
  
    If you only specify providers at the top level (typically the root `AppModule`), the tree of injectors appears to be flat.
    All requests bubble up to the root <code>NgModule</code> injector that you configured with the `bootstrapModule` method.
  