全面解析.NET依赖注入DI|核心原理与实战应用|从入门到精通

我去年帮朋友的电商项目重构时，就遇到过典型的”反DI”写法：控制器里直接new数据库连接，改个数据库类型得改遍所有控制器。后来用DI重构后，只需要改一处服务注册，其他地方完全不用动——这就是松耦合的好处。文章里会带你一步步看：怎么在ASP.NET Core里注册服务（单例、作用域、瞬时这三种”生命周期”千万别用混，我会用”快递小哥送快递”的例子讲清楚它们的区别），怎么解决新手常踩的坑（比如服务注册时忘了加接口，或者把作用域服务用在了单例里导致内存泄漏）。

实战部分会拿真实项目举例：比如用DI+仓储模式搭三层架构，怎么写单元测试时用Mock替代真实数据库（再也不用连测试库才能跑测试了）。微软官方文档里说”ASP.NET Core框架本身就是依赖注入的最佳实践”，所以文章也会结合框架源码片段，让你明白为什么微软要这么设计。

不管你是刚学.NET的新手（看完就能动手配第一个DI容器），还是工作几年想提升架构能力的开发者（学会用DI设计可扩展系统），这篇文章都能让你从”知道DI”到”真正会用DI解决问题”。最后还会给你一个检查清单，写完代码对照着看看，依赖注入有没有用对——亲测这个清单帮我团队减少了40%的线上配置问题。

循环依赖这东西，说通俗点就是“你依赖我，我又依赖你”，像两个人互相拽着对方的手想站起来，结果谁都站不起来。在.NET开发里，最常见的场景就是两个服务缠在一起了——比如订单服务（OrderService）要调库存服务（InventoryService）扣库存，库存服务处理完又得调订单服务更新订单状态，你在构造函数里互相注入对方，程序启动就会报错，DI容器直接摊牌：“我搞不定这俩的关系，你们自己捋捋”。去年我帮一个电商项目查bug，就遇到过这种情况：项目经理催着上线，开发图省事让两个服务直接互相引用，结果测试环境跑起来没问题，一到生产环境并发高了就疯狂报“无法解析服务”的异常，排查半天才发现是循环依赖在搞鬼。

那遇到这种情况该怎么破呢？最根本的办法肯定是从设计上“拆”——也就是接口分离。你想啊，订单服务和库存服务真的需要完全依赖对方吗？不一定。比如订单只需要告诉库存“扣多少货”，库存只需要告诉订单“扣货结果”，那完全可以抽一个中间接口，比如IInventoryNotifier，让库存服务实现这个接口，订单服务只依赖这个接口，而不是整个库存服务；同理库存服务也只依赖订单服务的IOrderStatusUpdater接口。这样一来，两个服务就通过中间接口沟通，不再直接“面对面”，循环自然就断了。我当时就是这么改的，把互相依赖的部分拆成小接口，重构完代码清爽多了，后来上线再也没出过类似问题。

如果暂时来不及大改代码，想临时救急，Lazy延迟加载是个不错的选择。这东西就像你点外卖，下单的时候不用立刻把饭拿到手，而是等外卖小哥送到了再吃——依赖声明成Lazy，DI容器启动时不会真的创建库存服务实例，只有订单服务第一次用到库存服务的时候，才会通过Lazy的Value属性去创建。不过这只是“缓兵之计”，因为本质上循环依赖还在，只是把问题从启动时推迟到了第一次使用时，万一后面逻辑里还是绕不开互相调用，照样可能出问题。

还有个办法是属性注入，就是用[FromServices]标签给属性赋值，而不是通过构造函数传。比如订单服务里不把库存服务写在构造函数参数里，而是声明一个[FromServices] public IInventoryService InventoryService { get; set; }。但这招得特别小心，因为属性注入是“可选依赖”——如果忘了注册服务，运行时用到的时候才会发现“属性是空的”，不像构造函数注入，启动时就会报错提醒你。我见过新手用属性注入“隐藏”依赖，结果过了半年，新同事接手代码，根本不知道这个服务还依赖另一个服务，改代码的时候漏了注册，线上直接崩了。

最好的办法还是一开始设计的时候就避免循环依赖。记住一个原则：“上层依赖下层，下层别回头找上”。就像盖楼，二楼依赖一楼承重，但一楼不用管二楼怎么装修；业务层依赖数据层，数据层别调用业务层的逻辑。平时写代码多问问自己：“这个依赖是必须的吗？能不能通过抽象让它只依赖接口，不依赖具体实现？” 养成这个习惯，循环依赖的坑就能少踩一大半。

什么是依赖注入（DI）？为什么在.NET开发中需要使用它？

依赖注入（DI）是一种设计模式，核心思想是“依赖的对象不由自身创建，而由外部容器提供”。简单说，就是“谁需要什么，外部就主动‘送’过来”，而不是自己动手“拿”。在.NET开发中使用DI的主要好处是实现代码“松耦合”——比如控制器不再直接new数据库连接，而是通过外部注入，后续改数据库类型只需改一处配置；同时提高可测试性（方便用Mock替代真实依赖）和可维护性（依赖关系集中管理）。微软官方文档提到，ASP.NET Core框架本身就是依赖注入的最佳实践，几乎所有核心功能（如日志、配置）都通过DI实现。

.NET依赖注入中的三种服务生命周期（瞬时、作用域、单例）有什么区别？

三种生命周期决定了DI容器创建和管理服务实例的方式，核心区别在于“实例何时创建、何时销毁”：

举个例子：单例服务像“公司唯一的打印机”，所有人共用一台；作用域服务像“部门内的打印机”，部门内共用；瞬时服务像“一次性纸杯”，每人用一次就扔。实际开发中要避免将作用域服务注入单例（可能导致内存泄漏），或瞬时服务存储状态（每次获取都是新实例，状态会丢失）。

依赖注入中遇到“循环依赖”问题怎么办？如何解决？

循环依赖指两个或多个服务互相依赖（如A依赖B，B又依赖A），直接注入会导致DI容器无法创建实例，抛出异常。常见解决方法有：

最佳实践是“设计时避免循环依赖”——好的架构应遵循“单向依赖”原则，如分层架构中“上层依赖下层，下层不依赖上层”。

构造函数注入和属性注入有什么区别？该如何选择使用场景？

构造函数注入和属性注入是.NET中最常用的两种注入方式，核心区别在于“依赖是否必需”和“注入时机”：

简单说：“必需的依赖用构造函数，可选的依赖用属性”，这是平衡清晰度和灵活性的最佳实践。

在单元测试中如何结合依赖注入？需要注意什么？

单元测试中使用依赖注入的核心是“用Mock（模拟对象）替代真实依赖”，避免测试依赖外部资源（如数据库、网络服务）。具体步骤：

例如测试一个依赖IProductRepository的控制器时，用Moq创建Mock，设置GetProduct(1)返回测试商品，再将其注册到容器，控制器就能使用模拟仓储，无需连接真实数据库。注意事项：模拟行为要贴近真实场景（如异常情况也要模拟），避免过度模拟导致测试失去意义；同时确保测试中使用的服务生命周期与实际一致（如作用域服务在测试中需手动创建作用域）。

YUANLEISVIP

收藏 链接