Unity依赖注入容器实战：从原理到应用，构建松耦合C#应用-平芜编程栈

1. 项目概述：为什么我们需要一个依赖注入容器？

在开发一个稍微复杂点的软件时，尤其是像游戏或者企业级应用，你很快会遇到一个头疼的问题：对象之间的依赖关系像一团乱麻。比如，你的PlayerController需要一个WeaponService，而WeaponService又依赖于DamageCalculator和AudioManager，AudioManager又需要ConfigLoader... 手动去new这些对象，然后在构造函数里一层层传递，代码会变得极其臃肿、难以测试，而且牵一发而动全身。

这就是依赖注入（Dependency Injection, DI）要解决的问题。它的核心思想是：一个类不应该自己创建它所依赖的对象，而是应该由外部“注入”给它。这带来了松耦合、高可测试性和更好的可维护性。而Unity Container，就是微软官方推出的一个轻量级、功能强大的依赖注入容器，它帮你自动化管理这些对象的创建和生命周期，让你从繁琐的依赖管理中解放出来。

我最初接触 Unity 是在一个遗留的 .NET Framework 项目里，当时项目里充斥着大量的new和静态类，单元测试几乎无法进行。引入 Unity 后，我们花了大约两周时间重构核心模块，代码的可测试性提升了不止一个档次，新功能的添加也顺畅了许多。最关键的是，Unity 的语法直观，学习曲线平缓，对于从零开始接触 DI 的团队来说，是个非常友好的选择。

本教程将基于我多次在项目中实战应用 Unity 的经验，从“为什么用”讲到“怎么用好”，不仅涵盖基础配置，更会深入探讨在实际开发中你会遇到的典型场景、决策取舍以及那些官方文档里不会写的“坑”。所有示例都可直接运行，你可以跟着一步步搭建，最终得到一个结构清晰、易于扩展的应用程序骨架。

2. 核心概念与Unity Container快速入门

在深入代码之前，我们必须统一几个关键概念，这是理解后续所有操作的基础。

2.1 依赖注入的三种方式与核心术语

依赖注入主要有三种实现方式：

构造函数注入：最推荐的方式。通过类的构造函数传入依赖项。这保证了对象在创建时就是完整可用的状态。

public class PlayerController { private readonly IWeaponService _weaponService; // 依赖通过构造函数注入 public PlayerController(IWeaponService weaponService) { _weaponService = weaponService; } }

属性注入：通过公共属性设置依赖。这种方式更灵活，但对象可能在某个阶段处于依赖不全的状态。
方法注入：通过特定方法传入依赖。通常用于单次操作。

在 Unity 的语境下，你需要熟悉这几个术语：

容器（Container）：IUnityContainer接口的实例。它是核心，负责管理类型注册和解析。
注册（Register）：告诉容器：“当需要类型 A 时，请创建（或返回）一个类型 B 的实例”。这里可能涉及接口和实现的映射，也可能涉及配置生命周期。
解析（Resolve）：向容器请求：“请给我一个类型 T 的实例”。容器会根据注册信息，自动创建该实例及其所有依赖。
生命周期管理器（Lifetime Manager）：控制已创建实例的生存期。例如，是每次解析都创建一个新的（瞬态），还是整个容器共享一个（单例）。

2.2 安装与第一个容器

Unity 的包现在主要通过Unity.Container提供。你可以通过 Visual Studio 的 NuGet 包管理器或者 .NET CLI 安装。

# 使用 .NET CLI 安装 dotnet add package Unity.Container

安装完成后，让我们创建第一个容器并完成一个最简单的注册-解析循环。

using Unity; using System; namespace UnityTutorial { // 1. 定义接口和实现 public interface IMessageService { string GetMessage(); } public class GreetingService : IMessageService { public string GetMessage() => "Hello from Unity Container!"; } class Program { static void Main(string[] args) { // 2. 创建容器实例 IUnityContainer container = new UnityContainer(); // 3. 注册：将接口 IMessageService 映射到实现 GreetingService // 默认是瞬态（Transient）生命周期，每次Resolve都new一个 container.RegisterType<IMessageService, GreetingService>(); // 4. 解析：容器自动创建 GreetingService 实例 var messageService = container.Resolve<IMessageService>(); // 5. 使用 Console.WriteLine(messageService.GetMessage()); // 输出: Hello from Unity Container! // 6. 验证生命周期：再次解析，得到的是另一个新实例 var anotherService = container.Resolve<IMessageService>(); Console.WriteLine($"Are they the same? {object.ReferenceEquals(messageService, anotherService)}"); // 输出: False } } }

这个简单的例子揭示了 Unity 的基本工作流：创建容器、注册类型、解析使用。但实际项目远比这复杂，我们接下来会逐步深入。

注意：在控制台应用或类库中手动创建和配置容器是常见的入门方式。但在 ASP.NET Core 等现代框架中，通常使用其内置的 DI容器，Unity 可以作为第三方容器集成进去。本教程重点讲解 Unity 容器本身的核心能力，掌握了这些，集成到任何宿主环境都是水到渠成。

3. 深入核心：注册、解析与生命周期管理

仅仅会注册和解析是远远不够的。如何组织注册代码？如何管理对象的生死？这才是体现设计功力的地方。

3.1 高级注册技巧

除了最基本的RegisterType<TFrom, TTo>()，Unity 提供了多种注册方式以适应不同场景。

命名注册：同一个接口可以有多个实现，通过名称来区分。

container.RegisterType<IMessageService, EmailService>("Email"); container.RegisterType<IMessageService, SmsService>("SMS"); // 解析时指定名称 var emailService = container.Resolve<IMessageService>("Email"); var smsService = container.Resolve<IMessageService>("SMS");

这在需要策略模式的地方非常有用，比如根据配置选择不同的日志输出器或支付网关。

注册现有实例：有时候你已经有一个现成的对象（比如一个配置复杂的单例），希望容器直接管理它。

var singletonInstance = new MyExpensiveService(); container.RegisterInstance<IMyService>(singletonInstance); // 之后任何解析 IMyService 的地方，得到的都是这个 singletonInstance

RegisterInstance默认使用容器控制的生命周期，通常意味着单例。

带参数的注册：当实现类的构造函数需要非依赖注入的参数时。

// 假设 GreetingService 构造函数需要一个前缀字符串 public class GreetingService : IMessageService { private readonly string _prefix; public GreetingService(string prefix) { _prefix = prefix; } public string GetMessage() => _prefix + " Hello!"; } // 注册时注入这个值 container.RegisterType<IMessageService, GreetingService>( new InjectionConstructor("【Debug】")); // 使用 InjectionConstructor

InjectionConstructor、InjectionProperty、InjectionMethod统称为Injection Members，是 Unity 进行显式配置的利器。

3.2 理解生命周期管理器

生命周期管理器决定了对象实例在容器内的“存活”时间。错误的生命周期设置是内存泄漏和状态混乱的常见根源。

Unity 提供了几种内置的生命周期管理器：

TransientLifetimeManager（默认）：每次调用Resolve都创建一个新实例。适用于无状态、轻量级的服务。
ContainerControlledLifetimeManager（容器控制单例）：在当前容器的生命周期内，只提供一个实例。相当于Singleton。适用于有状态、重量级、线程安全的服务（如配置服务、缓存服务）。
HierarchicalLifetimeManager（分层生命周期）：与子容器相关。在当前容器及其子容器中保持单例，但不同的子容器有不同的实例。
PerRequestLifetimeManager：主要在 Web 场景（如 WCF、ASP.NET）下使用，为每个请求创建一个实例。

如何选择？我的经验法则是：

默认用 Transient：除非有明确理由，否则优先选择 Transient。它最安全，避免了意外的状态共享。
谨慎使用 ContainerControlledLifetime：确保该服务确实是线程安全的，或者其状态是全局共享且可接受的。数据库上下文（DbContext）在 Web 应用中通常不能注册为容器单例，因为它是非线程安全的，应该使用 PerRequest 或 Scoped 生命周期（在支持 Scoped 的容器中）。

显式声明：即使想要默认的 Transient，我也建议显式写出来，提高代码可读性。

// 好的做法：清晰明了 container.RegisterType<IMyService, MyServiceImpl>(new TransientLifetimeManager()); // 或者使用 TypeLifetime 扩展方法（如果可用） container.RegisterType<IMyService, MyServiceImpl>().TypeLifetime(Lifetime.Transient);

3.3 解析的多种方式与子容器

基本解析：Resolve<T>()是最常用的。解析所有实现：当某个接口有多个命名注册时，可以一次性获取所有实例。

var allServices = container.ResolveAll<IMessageService>(); foreach(var service in allServices) { /* ... */ }

子容器：这是 Unity 一个强大但容易被忽视的特性。你可以从主容器创建一个子容器。

IUnityContainer childContainer = container.CreateChildContainer(); childContainer.RegisterType<IScopedService, ScopedServiceImpl>(new ContainerControlledLifetimeManager());

子容器会继承父容器的所有注册。
在子容器中进行的注册，只会影响该子容器及其后续创建的子容器。
生命周期为ContainerControlledLifetimeManager的对象，其作用域被限定在创建它的容器内。这意味着你在子容器中注册的单例，和父容器中的同名单例是不同的实例。
应用场景：在桌面应用中模拟“请求作用域”（Scoped），为每个窗口或工作单元创建子容器，工作完成后销毁子容器，其内的所有单例实例也会被释放，便于资源管理。

实操心得：避免在应用代码中频繁使用Resolve。理想情况下，只在组合根（应用程序的入口点，如Main方法、Startup.ConfigureServices）处解析一次顶级对象（如 MVC 的 Controller Factory 或主窗体）。让依赖从顶层对象像瀑布一样自动注入下去，这被称为“构造函数链”。如果你发现需要在业务逻辑里调用Resolve，99% 的情况是设计有问题，可以考虑引入抽象工厂模式。

4. 实战演练：构建一个简易游戏服务模块

让我们用一个更贴近实战的例子，把前面的知识串联起来。假设我们要为一个游戏构建一个简单的伤害计算系统。

4.1 定义领域模型与接口

首先，定义清晰的角色和武器接口，这是松耦合的基础。

// 角色接口 public interface ICharacter { string Name { get; } int Health { get; set; } void TakeDamage(int amount); } // 武器接口 public interface IWeapon { string WeaponName { get; } int CalculateDamage(ICharacter target); } // 伤害计算服务接口 public interface IDamageCalculator { int GetFinalDamage(int baseDamage, ICharacter attacker, ICharacter target); } // 战斗日志接口 public interface ICombatLogger { void LogDamage(ICharacter attacker, ICharacter target, IWeapon weapon, int damage); }

4.2 实现具体类并处理依赖

实现具体的角色、武器和服务。注意它们的依赖关系。

// 具体角色 public class Warrior : ICharacter { public string Name { get; } public int Health { get; set; } public Warrior(string name) { Name = name; Health = 100; } public void TakeDamage(int amount) { Health -= amount; Console.WriteLine($"{Name} 受到 {amount} 点伤害，剩余生命 {Health}"); } } // 具体武器：依赖伤害计算器 public class Sword : IWeapon { public string WeaponName => "钢铁长剑"; private readonly IDamageCalculator _damageCalculator; public Sword(IDamageCalculator damageCalculator) // 构造函数注入 { _damageCalculator = damageCalculator; } public int CalculateDamage(ICharacter target) { int baseDamage = new Random().Next(15, 25); // 这里简化了，实际攻击者信息可能需要额外传入 return _damageCalculator.GetFinalDamage(baseDamage, null, target); } } // 简单的伤害计算器：可能依赖角色属性、暴击率等（这里简化） public class SimpleDamageCalculator : IDamageCalculator { public int GetFinalDamage(int baseDamage, ICharacter attacker, ICharacter target) { // 模拟一个简单的浮动计算 return (int)(baseDamage * (0.8 + new Random().NextDouble() * 0.4)); } } // 控制台战斗日志器 public class ConsoleCombatLogger : ICombatLogger { public void LogDamage(ICharacter attacker, ICharacter target, IWeapon weapon, int damage) { Console.WriteLine($"[战斗日志] {attacker?.Name} 使用 {weapon.WeaponName} 对 {target.Name} 造成了 {damage} 点伤害。"); } }

4.3 使用Unity容器组装并运行

现在，在组合根（这里是Main方法）中，我们用 Unity 容器把这些零件组装起来。

using Unity; class Program { static void Main(string[] args) { // 1. 创建容器 IUnityContainer container = new UnityContainer(); // 2. 注册服务（通常生命周期为单例或瞬态） // 计算器和日志器是无状态的，可以用瞬态，但这里我们注册为容器单例，因为创建成本低且可全局共享。 container.RegisterType<IDamageCalculator, SimpleDamageCalculator>(new ContainerControlledLifetimeManager()); container.RegisterType<ICombatLogger, ConsoleCombatLogger>(new ContainerControlledLifetimeManager()); // 3. 注册武器。Sword 依赖 IDamageCalculator，容器会自动注入。 // 武器通常也是瞬态的，因为不同角色可能持有多把同类型武器实例。 container.RegisterType<IWeapon, Sword>(); // 4. 注册角色。角色通常不是由容器直接创建的（因为参数如名字是运行时决定的）， // 但我们可以注册一个工厂方法来创建它。这里为了演示，我们直接注册一个带参数的。 // 注意：通常角色实体不会通过容器解析，而是通过领域服务或工厂创建。 // 这里演示如何注册带参数的构造函数。 container.RegisterType<ICharacter, Warrior>(new InjectionConstructor("传奇勇士")); // 5. 解析并运行战斗模拟 var hero = container.Resolve<ICharacter>(); var weapon = container.Resolve<IWeapon>(); // 容器会自动为 Sword 注入 SimpleDamageCalculator var logger = container.Resolve<ICombatLogger>(); // 创建一个敌人（不通过容器，直接new） var enemy = new Warrior("哥布林喽啰"); Console.WriteLine($"战斗开始：{hero.Name} vs {enemy.Name}"); for (int i = 0; i < 3 && enemy.Health > 0; i++) { int damage = weapon.CalculateDamage(enemy); enemy.TakeDamage(damage); logger.LogDamage(hero, enemy, weapon, damage); } Console.WriteLine(enemy.Health > 0 ? "战斗继续！" : $"{enemy.Name} 被击败了！"); } }

运行这个程序，你会看到一次模拟的战斗过程，伤害计算和日志记录都通过依赖注入自动完成。这个例子展示了如何将多个相互依赖的服务通过容器优雅地组织起来。

5. 进阶主题：解决复杂依赖与设计模式

当系统变得复杂，你会遇到循环依赖、条件性依赖等问题。Unity 提供了一些机制来应对。

5.1 属性注入与方法注入

虽然构造函数注入是首选，但有些场景下属性注入更有用，比如依赖项是可选的，或者该依赖项在对象创建后才有意义。

public class BossCharacter : ICharacter { [Dependency] // 使用 Dependency 特性标记需要注入的属性 public ISpecialAbility? SpecialAbility { get; set; } // 可选的依赖 public void UseSpecialSkill() { SpecialAbility?.Activate(); } // ... 其他实现 } // 注册时，需要显式配置属性注入 container.RegisterType<ICharacter, BossCharacter>( new InjectionProperty(nameof(BossCharacter.SpecialAbility), new FireBreathAbility()));

方法注入则更少见，通常用于在对象初始化完成后注入某些依赖。

注意事项：滥用属性注入会使对象的依赖关系变得隐晦，难以从构造函数一眼看出。我个人的原则是：除非是真正的可选依赖（没有它对象也能正常工作），或者框架强制的场景（如某些 ASP.NET Web Forms 控件），否则坚持使用构造函数注入。

5.2 延迟解析与工厂模式

有时，你需要在运行时才能决定创建哪种类型的对象，或者不希望对象在解析父对象时立即被创建。这时可以使用Func<T>或自定义工厂。

Unity 内置的Func<T>支持：

// 注册类型 container.RegisterType<IWeapon, Sword>(); // 在依赖类中，可以注入 Func<IWeapon> public class WeaponMaster { private readonly Func<IWeapon> _weaponFactory; public WeaponMaster(Func<IWeapon> weaponFactory) { _weaponFactory = weaponFactory; } public IWeapon CreateWeapon() { return _weaponFactory(); // 每次调用都通过容器解析一个新的 IWeapon } }

这相当于一个轻量级的工厂，延迟了IWeapon的创建时机。

自定义抽象工厂：对于更复杂的创建逻辑，实现一个明确的工厂接口是更好的选择。

public interface IWeaponFactory { IWeapon CreateWeapon(WeaponType type); } public class UnityWeaponFactory : IWeaponFactory { private readonly IUnityContainer _container; public UnityWeaponFactory(IUnityContainer container) { _container = container; } public IWeapon CreateWeapon(WeaponType type) { switch (type) { case WeaponType.Sword: return _container.Resolve<Sword>(); case WeaponType.Bow: return _container.Resolve<Bow>(); default: throw new ArgumentOutOfRangeException(nameof(type)); } } } // 注册工厂本身为单例 container.RegisterType<IWeaponFactory, UnityWeaponFactory>(new ContainerControlledLifetimeManager());

这样，WeaponMaster就只依赖于IWeaponFactory，完全隐藏了具体武器类型和容器的细节，符合依赖倒置原则。

5.3 拦截器（Interception）实现AOP

面向切面编程（AOP）是处理横切关注点（如日志、缓存、异常处理、事务）的利器。Unity 内置了拦截器功能，可以在不修改业务代码的情况下，为已注册的类型动态添加行为。

首先，需要安装拦截器扩展包（如果使用的是较新的 Unity.Container，拦截器可能已内置或需要单独的包，请查阅对应版本的文档。经典 Unity 中是通过Unity.Interception包实现的）。

一个简单的日志拦截器示例：

using Unity.Interception.InterceptionBehaviors; using Unity.Interception.PolicyInjection.Pipeline; using System.Diagnostics; public class LoggingInterceptionBehavior : IInterceptionBehavior { public IMethodReturn Invoke(IMethodInvocation input, GetNextInterceptionBehaviorDelegate getNext) { // 方法调用前 Debug.WriteLine($"调用方法: {input.MethodBase.Name}, 参数: {string.Join(", ", input.Arguments)}"); // 执行原方法 var result = getNext()(input, getNext); // 方法调用后 if (result.Exception != null) { Debug.WriteLine($"方法 {input.MethodBase.Name} 抛出异常: {result.Exception.Message}"); } else { Debug.WriteLine($"方法 {input.MethodBase.Name} 执行完毕，返回值: {result.ReturnValue}"); } return result; } public IEnumerable<Type> GetRequiredInterfaces() => Type.EmptyTypes; public bool WillExecute => true; }

然后，在注册时应用这个拦截器：

// 使用接口拦截或虚方法拦截 container.RegisterType<IDamageCalculator, SimpleDamageCalculator>( new Interceptor<InterfaceInterceptor>(), // 使用接口拦截 new InterceptionBehavior<LoggingInterceptionBehavior>());

现在，每次调用IDamageCalculator的任何方法，都会自动输出日志。这极大地提高了系统的可观测性，并且将日志代码从业务逻辑中剥离了出来。

6. 集成与架构：在真实项目中应用Unity

Unity 很少单独使用，它需要集成到具体的应用程序框架中。

6.1 在WPF/WinForms应用中的使用

在桌面应用中，通常会在App.xaml.cs或程序启动入口创建并配置一个全局容器。

public partial class App : Application { public static IUnityContainer Container { get; private set; } protected override void OnStartup(StartupEventArgs e) { base.OnStartup(e); Container = new UnityContainer(); ConfigureContainer(Container); // 创建主窗口，其构造函数依赖的服务会自动注入 var mainWindow = Container.Resolve<MainWindow>(); mainWindow.Show(); } private void ConfigureContainer(IUnityContainer container) { // 注册所有服务、视图模型、数据访问层等 container.RegisterType<IMainViewModel, MainViewModel>(); container.RegisterType<IDataService, ApiDataService>(new ContainerControlledLifetimeManager()); // ... 更多注册 } }

在视图模型中，通过构造函数注入所需服务。

6.2 在ASP.NET Core中替换默认容器

ASP.NET Core 有强大的内置 DI 容器，但如果你需要 Unity 的某些特定功能（如更丰富的生命周期管理、拦截器等），可以替换它。

首先，安装Unity.Microsoft.DependencyInjection包。

dotnet add package Unity.Microsoft.DependencyInjection

然后在Program.cs中使用UseUnityServiceProvider方法：

var builder = WebApplication.CreateBuilder(args); // 使用 Unity 作为服务容器 builder.Host.UseUnityServiceProvider(); // 后续的注册可以通过 Unity 的 API，也可以继续使用 IServiceCollection // builder.Services.AddControllers(); // 这仍然有效，因为底层被 Unity 适配了 var app = builder.Build(); // ... 中间件配置 app.Run();

你还可以直接访问 Unity 容器进行更复杂的注册：

builder.Host.UseUnityServiceProvider(container => { // 在这里使用 container (IUnityContainer) 进行注册 container.RegisterType<IMyService, MyServiceImpl>(new HierarchicalLifetimeManager()); });

6.3 配置与模块化注册

对于大型项目，将所有注册代码写在一个地方是灾难。可以采用模块化注册。

// 定义注册模块接口 public interface IUnityModule { void Register(IUnityContainer container); } // 实现业务模块注册 public class DataAccessModule : IUnityModule { public void Register(IUnityContainer container) { container.RegisterType<IRepository<User>, UserRepository>(); container.RegisterType<IDbContext, AppDbContext>(new HierarchicalLifetimeManager()); } } public class BusinessLogicModule : IUnityModule { public void Register(IUnityContainer container) { container.RegisterType<IUserService, UserService>(); // ... 其他业务服务 } } // 在启动时加载所有模块 public static void ConfigureContainer(IUnityContainer container) { var modules = new List<IUnityModule> { new DataAccessModule(), new BusinessLogicModule(), // ... 从配置或程序集扫描加载更多模块 }; foreach (var module in modules) { module.Register(container); } }

这种方式使得每个功能模块的依赖关系保持内聚，易于管理和维护。

7. 常见问题、性能调优与避坑指南

即使理解了所有概念，在实际项目中还是会踩坑。下面是我总结的一些典型问题和解决方案。

7.1 典型错误与排查

问题1：ResolutionFailedException- 容器无法解析类型。

原因：最常见的原因是类型没有注册，或者注册的生命周期与解析的上下文不匹配（例如，在子容器中解析一个只在父容器注册的瞬态服务，有时没问题，但如果是单例就可能出问题）。
排查：
1. 检查异常信息，它会明确指出哪个类型无法解析，以及它的哪个依赖项出了问题。
2. 确认依赖链上的每一个接口和具体类都已经正确注册。
3. 检查构造函数是否是public的。Unity 默认需要公共构造函数。
4. 检查是否存在循环依赖（A 依赖 B，B 又依赖 A）。这通常意味着设计有问题，需要引入抽象或调整依赖方向。

问题2：内存泄漏。

原因：错误地使用了生命周期管理器。将本应是瞬态的、持有大量资源（如数据库连接、文件句柄）的对象注册为容器控制单例，并且没有提供释放机制。
解决：
- 确保实现了IDisposable的对象被正确管理。Unity 容器在自身被释放时，会释放所有由它创建的、实现了IDisposable的单例实例。但对于瞬态实例，容器不会跟踪，需要调用者自己释放。
- 对于非单例但需要资源管理的对象，考虑使用工厂模式，在工厂中管理其生命周期。
- 善用子容器。为具有明确生命周期的操作单元（如一个后台任务、一个用户会话）创建子容器，任务完成后销毁子容器，其内所有单例实例也会被释放。

问题3：性能问题。

原因：过度使用反射，或者在热路径上频繁解析对象。
优化：
- 预热：在应用程序启动时，提前解析那些复杂的、依赖链长的根对象一次，让容器完成所有的反射和表达式树编译工作。
```
// 在配置完容器后 container.RegisterType<IMyComplexService, MyComplexServiceImpl>(); // 预热 var warmUpInstance = container.Resolve<IMyComplexService>(); // 可以根据需要决定是否立即释放 warmUpInstance
```
- 避免在循环或高频方法中调用Resolve：依赖应该在构造函数或高层一次性注入。
- 使用子容器需谨慎：创建子容器有一定开销，不要为每个微小操作都创建。

7.2 设计原则与最佳实践

面向接口编程：这是使用 DI 容器的前提。所有服务都应依赖于抽象（接口或抽象类）。
构造函数注入为主：保持依赖关系明确。
保持构造函数简单：构造函数只应接受必要的依赖，不应包含业务逻辑。如果一个类依赖过多（比如超过5个），可能是违反了单一职责原则，需要考虑拆分。
组合根：将对象的创建和组装逻辑限制在应用程序的入口点附近。这是控制反转（IoC）的核心。
避免服务定位器模式：不要将IUnityContainer本身作为依赖注入到各个类中（这被称为“服务定位器”反模式）。这会隐藏类的真实依赖，使代码难以理解和测试。

7.3 Unity与其他容器的简要对比

你可能会听到 Autofac、DryIoc、Microsoft.Extensions.DependencyInjection（内置）等其他容器。简单对比一下：

Unity：功能全面（拦截、扩展性好），文档历史丰富，在遗留和企业级 .NET Framework 项目中常见。性能在早期版本中不是最优，但新版本有改善。
Autofac：模块化注册非常强大，性能优秀，社区活跃，是许多新项目的热门选择。
DryIoc：以极致的运行速度著称，语法简洁。
内置容器（Microsoft）：轻量、集成度最高，满足大部分基础需求，但不支持属性注入、子容器等高级功能。

如何选择？对于新项目，如果不需要 Unity 特有的高级功能（如复杂的拦截），从Microsoft.Extensions.DependencyInjection开始是最稳妥的，它简单、官方支持、与 ASP.NET Core 生态无缝集成。当需求超出其能力时，再考虑替换为 Autofac 或 DryIoc。Unity 则更多是在维护现有项目或团队已有深厚 Unity 经验时的选择。

最后，记住 DI 容器的目的是让代码更好，而不是更复杂。如果引入容器让简单的项目变得难以理解，那就违背了初衷。从小的模块开始实践，逐步体会它带来的解耦和可测试性的好处，你会越来越依赖这种优雅的代码组织方式。