anchor.diff:      
   :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.
  
positive.code:   The setter initializes the component's own instance of the `HeroTaxReturnService` with the incoming return.
    The getter always returns what that service says is the current state of the hero.
    The component also asks the service to save and restore this tax return.
  
    There'd be big trouble if _this_ service were an application-wide singleton.
    Every component would share the same service instance.
    Each component would overwrite the tax return that belonged to another hero.
    What a mess!
  
    Look closely at the metadata for the `HeroTaxReturnComponent`. Notice the `providers` property.
  
  +makeExcerpt('src/app/hero-tax-return.component.ts', 'providers', '')
  
  
negative.code:   That would be a pretty easy task for a simple hero tax return.
    In the real world, with a rich tax return data model, the change management would be tricky.
    You might delegate that management to a helper service, as this example does.
    
    实现方式之一就是让`HeroTaxReturnComponent`有逻辑来管理和还原那些更改。
    这对于简单的报税单来说是很容易的。
    不过，在现实世界中，报税单的数据模型非常复杂，对这些修改的管理可能不得不投机取巧。
    于是我们可以把这种管理任务委托给一个辅助服务，就像这个例子中所做的。
  
    Here is the `HeroTaxReturnService`.
    It caches a single `HeroTaxReturn`, tracks changes to that return, and can save or restore it.
    It also delegates to the application-wide singleton `HeroService`, which it gets by injection.
    
    这是一个报税单服务`HeroTaxReturnService`。
    它缓存了单条`HeroTaxReturn`，用于跟踪那个申报单的变更，并且可以保存或还原它。
    它还委托给了全应用级的单例服务`HeroService`，它是通过依赖注入机制取得的。
  
  +makeExample('src/app/hero-tax-return.service.ts')
  
  :marked
    Here is the `HeroTaxReturnComponent` that makes use of it.
    
    下面是正在使用它的`HeroTaxReturnComponent`组件。
  
  +makeExample('src/app/hero-tax-return.component.ts')
  
  