7 道 DI 面试真题 + 完整解析,吃透直接拿下中高级.NET 开发 offer
- 2026-09-23 12:29:49
在 .NET 中高级开发面试中，依赖注入（Dependency Injection, DI） 是绕不开的核心考点。面试官不会只停留在 “三种生命周期是什么” 的基础题，而是会深挖容器原理、生命周期陷阱、高级扩展与生产环境踩坑经验。
今天整理了 7 道一线互联网 / 中大厂高频 DI 面试真题，从基础到高阶全覆盖，每道题附带深度解析 + 可运行代码示例 + 面试加分回答，吃透后足以应对 90% 以上的 .NET DI 相关面试。
第 1 题：说说 .NET 内置 DI 的三种服务生命周期，以及它们的适用场景
考察点
基础概念掌握程度，是否理解生命周期本质差异，能否结合业务场景选型。
完整解析
.NET 内置依赖注入容器定义了三种核心服务生命周期，本质区别在于服务实例的创建时机与存活范围：
| Transient（瞬时） | |||
| Scoped（作用域） | |||
| Singleton（单例） |
适用场景与选型建议
- Transient
：轻量级、无状态的服务，如工具类、辅助方法、纯计算逻辑。优点是不会有并发安全问题，缺点是频繁创建销毁有性能开销。 - Scoped
：Web 应用中最常用，与 HTTP 请求绑定，如数据库上下文（DbContext）、当前用户信息、请求级缓存。绝对不能在 Singleton 中直接注入 Scoped 服务（后面第 4 题会详细讲坑点）。 - Singleton
：全局共享、初始化成本高的服务，如配置对象、全局缓存、连接池管理、日志工厂。使用时必须考虑线程安全。
三种生命周期本质是实例复用粒度的不同。选型核心原则：能使用 Scoped 就不用 Singleton，能使用 Transient 就不用 Scoped，尽量缩小服务的存活范围，减少内存占用与并发风险。另外要注意，Singleton 服务如果实现了 IDisposable，容器会在应用退出时释放；而 Transient 和 Scoped 服务会在所属作用域销毁时自动释放。
第 2 题：AddSingleton 与 TryAddSingleton 有什么区别？TryAdd 系列方法的作用是什么？
考察点
对 DI 容器注册行为的理解，是否知道服务重复注册的覆盖规则，是否了解防御式注册。
完整解析
这是中高级面试高频题，很多开发者只用过 AddXXX，但没注意过 TryAddXXX 的区别。
直接向容器注册服务，允许重复注册。 当同一服务类型注册多次时，最后一次注册生效（覆盖前面的实现）。 解析单个服务时取最后一个；解析 IEnumerable<T>时会返回所有注册的实例。
属于防御式注册：只有当该服务类型尚未被注册时，才会执行注册。 如果容器中已经存在该服务类型的注册，直接跳过，不覆盖原有实现。 对应的还有 TryAddScoped、TryAddTransient、TryAddEnumerable等方法。
典型应用场景
TryAdd 系列最常用于框架扩展与库开发。比如你写一个类库，提供默认的服务实现，但又希望使用者可以在外部提前注册自己的实现来覆盖默认值，此时就应该用 TryAdd 注册默认服务，避免强行覆盖用户配置。
TryAdd 本质是 “注册保底值” 的设计模式，遵循 “用户注册优先” 原则。另外扩展一下：TryAddEnumerable 用于集合注册，它会检查实现类型是否已存在，避免同一个实现被重复加入集合中。
第 3 题：构造函数注入、属性注入、方法注入有什么区别？.NET 原生支持哪几种？
考察点
对 DI 注入方式的理解，是否了解各种注入的适用场景，以及对 .NET DI 容器能力边界的认知。
完整解析
- .NET 原生支持，也是官方推荐的主流方式
。 在类的构造函数中声明依赖，由容器在创建实例时自动传入。 优点：依赖显式声明，不可缺失，对象创建即处于完整可用状态，便于单元测试。 适用：绝大多数业务场景，是首选注入方式。
- .NET 内置 DI 容器原生不支持
，需要第三方容器（如 Autofac、Unity）或手动实现。 通过公共属性赋值来注入依赖。 优点：可选依赖，对象可先创建再赋值。 缺点：依赖不透明，容易出现空引用异常，不推荐业务开发使用。
.NET 原生支持，主要体现在两种场景： 中间件的 Invoke/InvokeAsync方法中直接注入服务调用 GetService时通过参数手动传入特点：仅在方法执行时需要该依赖，不需要保存为类成员。 典型场景：中间件中注入 Scoped 服务（因为中间件本身是 Singleton）。
.NET 内置 DI 只支持构造函数注入和方法注入，不支持属性注入，这也是它被称为 “轻量级容器” 的原因之一。属性注入常见于第三方容器，一般用于可选依赖或 AOP 场景。在业务开发中，应该优先使用构造函数注入，保证依赖的显式性和完整性。
第 4 题：在 Singleton 服务中注入 Scoped 服务会发生什么？如何正确解决？
考察点
生命周期陷阱，这是中高级必考题，直接区分初级和中高级开发者。考察是否踩过坑、是否理解作用域概念。
完整解析
直接注入的后果
在 Singleton 服务的构造函数中直接注入 Scoped 服务，会导致该 Scoped 服务被提升为单例，也就是常说的 “生命周期污染”。
原因很简单：Singleton 服务只创建一次，它的依赖也只会在创建时解析一次，于是这个 Scoped 服务就跟着 Singleton 一直存活，失去了 “每个请求创建一次” 的语义。
这会引发严重问题：
数据库连接长时间不释放，导致连接池耗尽 多线程并发访问非线程安全的 Scoped 服务，引发数据错乱 请求级数据串用，出现脏数据
正确解决方案
核心原则：手动创建作用域，在作用域内解析服务，用完立即释放。
有两种常用实现方式：
方案一：注入 IServiceScopeFactory（推荐）
方案二：注入 IServiceProvider（不推荐直接解析）
直接注入 IServiceProvider 然后 CreateScope() 也可以，但 IServiceScopeFactory 语义更明确，是专门用来创建作用域的。
面试加分回答
这是 .NET DI 最经典的坑点，本质是长生命周期服务不能依赖短生命周期服务。除了手动创建作用域，另一种思路是从设计上规避：如果某个服务需要 Scoped 依赖，那它本身就不应该设计成 Singleton。实在需要跨作用域访问，一定要用 IServiceScopeFactory 手动控制作用域边界，并且用 using 保证释放。
第 5 题：.NET 8 引入的 Keyed Services 是什么？解决了什么问题？
考察点
对 .NET 新特性的关注度，是否了解同一接口多实现的区分注册方案，技术跟进能力。
完整解析
在 .NET 8 之前，如果同一个接口有多个实现类，我们只能通过集合注入 IEnumerable<T> 然后自己判断，非常不方便。Keyed Services（键控服务）就是为了解决这个问题：用一个 Key 来标识同一接口下的不同实现，按需解析。
代码示例
[FromKeyedServices] 特性直接注入：
替代了之前 “注入集合 + 遍历匹配” 的繁琐写法 同一接口多实现场景下，注册和解析语义更清晰 支持策略模式、工厂模式的优雅实现
Keyed Services 是 .NET 内置 DI 的重要补强。它的 Key 可以是任意对象，不只是字符串。对应的也有 TryAddKeyedSingleton 等防御式注册方法。不过要注意，Keyed 服务不能和普通非 Keyed 服务混用解析，必须用对应的 GetKeyedService 方法。
第 6 题：如何在 .NET DI 中实现装饰器模式？
考察点
DI 高级用法，设计模式与容器的结合，对服务注册底层的理解。
完整解析
装饰器模式是指：不修改原有类，动态地给对象添加额外功能。在 DI 容器中实现装饰器，就是让容器解析服务时，自动把原始实现包装进装饰器中。
.NET 内置 DI 没有专门的装饰器注册方法，但可以通过手动注册工厂的方式实现。
代码示例
进阶：多层装饰器
如果有多个装饰器（日志 + 缓存 + 审计），可以层层嵌套，工厂方式可以灵活控制装饰顺序。
面试加分回答
.NET 内置 DI 没有 Decorate 这样的便捷方法，这一点不如 Autofac 等第三方容器，但通过工厂注册完全可以实现。生产环境中，装饰器模式常用于横切关注点（日志、缓存、权限、性能监控），比直接改业务代码更符合开闭原则。
第 7 题：如果默认 DI 容器不满足需求，如何替换成第三方容器？比如 Autofac
考察点
对 DI 容器扩展点的理解，IServiceProviderFactory 抽象，中大型项目架构能力。
完整解析
.NET 的依赖注入体系设计了抽象层，允许替换底层容器实现。核心接口是 IServiceProviderFactory<TContainerBuilder>。
替换 Autofac 的步骤
安装 NuGet 包： Autofac.Extensions.DependencyInjection在 Program.cs中调用UseServiceProviderFactory
为什么要替换第三方容器
内置 DI 满足 80% 场景，但大型项目可能需要：
属性注入 按约定批量注册 更强大的装饰器支持 AOP 动态代理 更细粒度的生命周期控制
替换容器的核心是 IServiceProviderFactory 这个抽象，它负责把 IServiceCollection 里的注册信息转换成第三方容器的内部结构。所以即使换了容器，之前用 AddScoped 等方式注册的服务依然有效，不会失效。选型上，简单项目用内置 DI 足够，复杂架构再考虑 Autofac 等第三方容器，不要为了炫技而过度设计。
写在最后
DI 不只是一个面试考点，更是 .NET 架构设计的基石。从基础生命周期选型，到生命周期坑点规避，再到键控服务、装饰器、容器替换，每一层都对应着不同级别的工程能力。
面试时回答这类问题的技巧是：先答基础定义，再讲原理本质，最后结合生产场景说踩坑经验和最佳实践，这样很容易拉开和其他候选人的差距。
资料
常见坑点与解决方案清单 15 道 DI 高阶面试题完整解析 Autofac 集成最佳实践代码 7 道题的完整 Demo + 单元测试
