下一个依赖注入系列是注入()函数。你可能熟悉使用类构造函数注入服务，如下所示:
我们也可以用注入函数来做同样的事情:
的注入函数可以在3个不同的地方使用。我们可以在初始化“Angular”类(组件/服务/管道/指令/模块)的字段时使用它，也可以在此类类的构造函数体中使用:
现在，我们可以将该函数视为一种语法选择。也就是说，我们必须尽快开始使用它，因为路由器类守卫在Angular 15.2中已弃用．而另一种选择是可能需要注入依赖项的功能保护——使用注入功能:
昨天，我们看到如何使用组件(和模块)层次结构来配置依赖注入角。
今天，让我们看看如何使依赖注入成为有条件的。例如，假设我们有一个LoginService对于需要在开发阶段无法使用或我们不想在开发阶段使用的特性的产品。
然后我们可以做的是配置我们的提供者来根据当前环境做出决定:
使用三元运算符(如果属实)?[那么这个]:[否则那]，我们可以决定什么时候使用服务而不是替代版本。
如果需要根据其他因素(例如来自其他服务的数据)做出依赖项注入决策，或者有几个不同的可能的服务要注入，则可以使用依赖于其他服务的工厂函数(deps)注入到工厂函数中，如下所示:
中的依赖项的顺序deps必须与传递给工厂函数的参数的顺序匹配useFactory．
昨天，我们讲了配置提供者的不同选项与providedIn语法。今天，让我们来看看Angular是如何解决依赖注入的分层的喷油器．
假设我们有aButtonComponent这需要一个LoginService．Angular会检查的注入器ButtonComponent看看是否LoginService是否可用(因为所有组件都有自己的注入器，可配置数组of供应商或者是providedIn语法)。
假设组件注入器不知道这个服务。在这种情况下，它会问它的父组件，然后是祖父组件，沿着组件层次结构往上走，直到它到达应用的根注入器:
这些被称为分层的喷油器:它们依赖于我们的组件层次结构。这解释了为什么在组件级别更改提供者的配置会影响组件及其所有子组件。
如果在组件树中找不到服务，Angular就会使用类似的解析路径模块的层次结构，从子模块一直到AppModule．
如果没有找到服务，Angular就会抛出一个错误，指出该服务没有可用的提供商。
作为Angular开发人员，我们经常使用和创建服务。所以，在今天的文章中，让我们揭开下面语法的神秘面纱，看看它有哪些不同的选项:
当服务为在根注入器中提供（providedIn:“根”)，这意味着这样的服务可以被注入到应用程序的任何组件中，并且该服务将是应用程序中所有消费者共享的单例服务。
如果要限制服务的范围，可以在模块或者一个组件而不是根注入器。语法是这样的——我们使用目标模块或组件的类名:
当一个模块提供服务时，只有该模块的组件/指令/管道/服务可以注入该服务。然而，当在组件中提供时，该组件和它的孩子可以注入该服务。
从语法的角度来看，提到using也是很重要的providedIn相当于在组件或模块中执行以下操作:
上述代码等价于以下代码:
所以你只需要其中一个;两者都是多余的。
最后，还有另一种选择:平台．
该服务可以被注入到当前浏览器选项卡中的任何Angular应用中。这是一个罕见的用例，但如果你在同一个页面上运行多个Angular应用程序，并且想在这些应用程序之间共享服务，平台是你需要的。
欲了解更多信息，请阅读我的那篇文章涵盖了所有这些选项(注意:providedIn:“任何”以前是一个选项，但现在已弃用，这就是为什么我没有提到它)
