依赖注入玩坏，是哪一步出了差错？

前言 自从.NET Core给我们呈现了依赖注入，在我们项目中到处充满着依赖注入，虽然一切都已帮我们封装好，但站在巨人的肩膀上，除了凭眺远方，我们也应平铺好脚下的路，使用依赖注入不仅仅只是解耦，而且使代码更具维护性，同时我们也可轻而易举查看依赖关系，单元测试也可轻松完成，本文我们来聊聊依赖注入，文中示例版本皆为5.0。 浅谈依赖注入 在话题开始前，我们有必要再提一下三种服务注入生命周期，由浅及深再进行讲解，基础内容，我这里不再多述废话 Transient（瞬时）：每次对瞬时的检索都会创建一个新的实例。 Singleton（单例）：仅被实例化一次。此类型请求，总是返回相同的实例。 Scope（范围）：使用范围内的注册。将在请求类型的每个范围内创建一个实例。 如果已用过.NET Core一段时间，若对上述三种生命周期管理的概念没有更深刻的理解，我想有必要基础回炉重塑下。为什么？至少我们应该得出两个基本结论 其一：生命周期由短到长排序，瞬时最短、范围次之、单例最长 只要做过Web项目，关于第一点就很好理解，首先我们只对瞬时和范围作一个基本的概述，关于单例通过实际例子来阐述，我们理解会更深刻 若为瞬时：那么我们每次从容器中获取的服务将是不同的实例，所以名为瞬时或短暂 若为范围：在ASP.NET Core中，针对每个HTTP请求都会创建DI范围，当在HTTP请求中（在中间件，控制器，服务或视图中）请求服务，并且该服务注册为范围服务时，如果在请求中多次请求相同类型的请求，则使用相同实例。例如，如果在控制器，服务和视图中注入了范围服务，则将返回相同的实例。随着另一个HTTP请求的流，使用了不同的实例，请求完成后，将处理（释放）范围 其二：被注入的服务应与注入的服务应具有相同或更长的生命周期 从概念上看貌似有点拗口，通过日常生活举个栗子则秒懂，假设有两个桶，一个小桶和一个大桶，我们能将小桶装进大桶，但不能将大桶装进小桶。