1. 项目概述为什么我们要告别 MonoBehaviour如果你在 Unity 里写过几年代码大概率会对MonoBehaviour又爱又恨。爱它上手快一个脚本挂到 GameObject 上就能跑恨它带来的“面条式”代码——业务逻辑、数据管理、生命周期、UI 更新全搅在一起项目稍微大点改一处动全身测试更是无从下手。这感觉就像把家里所有东西都堆在客厅找把剪刀都得翻半天。最近几年随着 Unity 项目复杂度的飙升尤其是手游长线运营和 3A 大作的工业化需求这种基于MonoBehaviour的传统架构越来越力不从心。你会发现团队里资深的程序员开始频繁讨论“依赖注入”、“控制反转”、“领域驱动设计”这些词。这不是在炫技而是在解决实实在在的工程痛点如何让代码更清晰、更易测试、更易维护、更易扩展。VContainer正是在这个背景下进入我们视野的。它不是一个全新的概念而是将 .NET 生态中久经考验的依赖注入DI模式以一种对 Unity 开发者极其友好的方式引入进来。简单说它帮你管理对象之间的依赖关系。以前是你自己new一个类或者用GetComponent去硬找现在是你告诉容器“我需要一个这样的服务”容器自动帮你创建好并传递过去。代码从“主动拉取依赖”变成了“被动接收依赖”这就是“控制反转”。告别MonoBehaviour不是说要完全不用它——毕竟 Unity 的 GameObject 和组件系统是引擎核心。而是说我们要告别那种“一个MonoBehaviour脚本承载所有”的粗放模式将核心的业务逻辑、数据、服务从MonoBehaviour中剥离出来变成纯粹的 C# 类。MonoBehaviour则退化为纯粹的“视图层”或“适配器”只负责与 Unity 引擎交互比如接收Update、处理点击事件、播放动画。VContainer就是粘合这两层并管理它们之间依赖关系的“胶水”。这么做的好处是立竿见影的你的业务代码变成了可以独立单元测试的纯 C# 类类与类之间通过接口耦合替换实现只需改一行配置系统的依赖关系一目了然新人也能快速理清模块脉络。接下来我们就深入拆解如何用VContainer一步步重构你的 Unity 项目实现更优雅的代码架构。2. 核心设计思路依赖注入如何重塑 Unity 项目结构在动手写代码之前我们必须把设计思路理清楚。依赖注入不是银弹用错了地方反而会增加复杂度。我们的目标是建立一个清晰、松散耦合的分层架构。2.1 传统架构 vs. VContainer 架构对比我们先看一个典型场景一个玩家角色需要攻击敌人。在传统MonoBehaviour写法里PlayerController脚本里可能会直接出现这些代码public class PlayerController : MonoBehaviour { private EnemyManager _enemyManager; private Weapon _currentWeapon; private AudioSource _audioSource; private ParticleSystem _hitEffect; void Start() { // 1. 自己找依赖 _enemyManager FindObjectOfTypeEnemyManager(); if (_enemyManager null) { Debug.LogError(找不到 EnemyManager); } _currentWeapon GetComponentInChildrenWeapon(); _audioSource GetComponentAudioSource(); _hitEffect GetComponentInChildrenParticleSystem(); // 2. 可能还有各种单例、静态访问 GameState.Instance.OnPaused HandlePause; } void Update() { if (Input.GetButtonDown(Fire1)) { // 3. 业务逻辑、资源调用、UI更新全混在一起 var target _enemyManager.GetNearestEnemy(transform.position); if (target ! null _currentWeapon.CanAttack()) { bool isCritical Random.value _critRate; int damage CalculateDamage(isCritical); target.TakeDamage(damage); _audioSource.PlayOneShot(_hitSound); _hitEffect.Play(); UIManager.Instance.ShowDamageText(damage, target.transform.position); _currentWeapon.Cooldown(); } } } private int CalculateDamage(bool isCritical) { /* ... */ } }这段代码问题太多了难以测试依赖FindObjectOfType、GetComponent、单例、职责混杂、EnemyManager和UIManager紧耦合。一旦想换种攻击方式或者做单元测试简直是一场灾难。使用VContainer重构后代码会拆分成多个职责单一的类并通过构造函数注入依赖// 纯粹的业务逻辑类不继承 MonoBehaviour可独立测试 public class PlayerAttackService { private readonly IEnemyManager _enemyManager; private readonly IWeapon _weapon; private readonly IAudioService _audioService; private readonly IEffectService _effectService; private readonly IDamageCalculator _damageCalculator; // 依赖通过构造函数注入关系一目了然 public PlayerAttackService( IEnemyManager enemyManager, IWeapon weapon, IAudioService audioService, IEffectService effectService, IDamageCalculator damageCalculator) { _enemyManager enemyManager; _weapon weapon; _audioService audioService; _effectService effectService; _damageCalculator damageCalculator; } public void ExecuteAttack(Vector3 playerPosition) { var target _enemyManager.GetNearestEnemy(playerPosition); if (target null || !_weapon.CanAttack()) return; var damageInfo _damageCalculator.Calculate(); target.TakeDamage(damageInfo); _audioService.PlayHitSound(); _effectService.PlayHitEffect(target.Position); _weapon.Cooldown(); } } // MonoBehaviour 退化为薄薄的“视图层” public class PlayerController : MonoBehaviour { // 依赖由 VContainer 注入 [Inject] private PlayerAttackService _attackService; [Inject] private IInputService _inputService; void Update() { if (_inputService.GetAttackButtonDown()) { _attackService.ExecuteAttack(transform.position); } } }看到区别了吗PlayerAttackService只关心攻击的业务逻辑它不知道声音怎么播、特效怎么放、UI 怎么显示它只通过接口调用其他服务。所有依赖都是从外部“注入”进来的这使得每个类都高度独立、可替换、易测试。2.2 分层架构设计基于 VContainer我推荐采用一种简化的分层架构适用于大多数中大型 Unity 项目领域层Domain Layer最核心的业务逻辑和规则。包含实体如Player、Enemy、值对象如DamageInfo、领域服务如PlayerAttackService。这一层应该是纯粹的 C# 类绝对不引用任何 Unity 的 API如UnityEngine、UnityEditor。这保证了核心逻辑的可测试性和可移植性。应用层Application Layer协调领域对象完成具体的用例或业务流程。例如StartNewGameCommand、PurchaseItemCommand。它依赖于领域层并调用基础设施层的服务。基础设施层Infrastructure Layer为其他层提供具体的技术实现。例如UnityAudioService实现IAudioService内部调用AudioSource。UnityInputService实现IInputService内部封装Input类。AddressableAssetProvider实现IAssetProvider负责资源加载。网络通信、本地存储等实现也在这里。表现层Presentation Layer即 Unity 的 MonoBehaviour 脚本、UI 视图UGUI/UI Toolkit、动画控制器等。它们职责单一响应用户输入、调用应用层服务、监听领域事件更新 UI 显示。它们通过[Inject]属性或构造函数来获取需要的服务。VContainer的核心作用就是作为一个“粘合剂”在启动时或场景加载时将这些分层组装起来创建好所有对象并正确注入它们的依赖关系。实操心得接口先行在开始编码前先花时间定义好层与层之间的接口如IAudioService、IInputService。这强迫你思考每个模块的职责和边界而不是一上来就写具体实现。即使最初只有一个实现定义接口也能极大提升代码的清晰度和可测试性。3. VContainer 核心概念与基础配置详解理解了设计思路我们来具体看看VContainer怎么用。首先通过 Package Manager 的 Git URL 安装它https://github.com/hadashiA/VContainer.git。或者直接下载 UnityPackage。3.1 Lifetime对象生命周期管理这是VContainer里最重要的概念之一决定了被注册对象的存活范围。选错了生命周期可能会导致内存泄漏或状态混乱。Transient瞬态每次请求都创建一个新实例。适用于无状态、轻量的服务或者每次都需要新对象的场景如DamageInfo值对象。builder.RegisterDamageCalculator(Lifetime.Transient);Scoped作用域在一个特定的“作用域”内是单例。这是非常强大的特性。例如你可以为每个游戏关卡创建一个作用域关卡的专属服务如LevelManager在这个作用域内是唯一的关卡结束后作用域被释放这些服务也随之销毁完美管理内存。using var scope _container.CreateScope(); var levelManager scope.ResolveILevelManager();Singleton单例在整个容器生命周期内只有一个实例。适用于全局管理器、配置数据等。builder.RegisterGameStateManager(Lifetime.Singleton);注意事项Singleton 与 MonoBehaviour将MonoBehaviour注册为Singleton时要格外小心。如果该MonoBehaviour挂载在场景中的 GameObject 上你应该使用RegisterComponentInHierarchy或RegisterInstance来注册已存在的实例而不是让容器去new一个。否则你会得到两个实例一个由容器管理一个在场景中会导致难以调试的行为。3.2 多种依赖注入方式VContainer 提供了灵活的注入方式适应不同场景。构造函数注入首选依赖通过类的构造函数参数传入。这是最推荐的方式因为它明确声明了一个类正常运行所需要的所有依赖并且强制这些依赖在创建时就被满足。public class PlayerAttackService { private readonly IWeapon _weapon; public PlayerAttackService(IWeapon weapon) // 构造函数注入 { _weapon weapon; } } // 注册时VContainer 会自动解析 IWeapon 并传入 builder.RegisterPlayerAttackService(Lifetime.Scoped); builder.RegisterIWeapon, SwordWeapon(Lifetime.Scoped);方法注入依赖通过一个标记了[Inject]特性的公共方法传入。这在某些需要依赖但又不方便改构造函数的场景有用比如MonoBehaviour的Awake或Start阶段进行注入。public class PlayerView : MonoBehaviour { private IHealthDisplay _healthDisplay; [Inject] public void Construct(IHealthDisplay healthDisplay) // 方法注入 { _healthDisplay healthDisplay; } }属性/字段注入通过标记[Inject]特性在字段或属性上。这种方式最方便但也最不推荐在业务逻辑层使用因为它隐藏了类的依赖关系让类看起来可以无依赖运行但实际上不行。它更适合在纯粹的视图层MonoBehaviour中使用因为这些脚本的创建由 Unity 控制我们无法使用构造函数注入。public class GameUI : MonoBehaviour { [Inject] private IScoreService _scoreService; // 属性/字段注入 [Inject] private IEventPublisher _eventPublisher; }3.3 启动与作用域创建通常我们会在游戏入口点如一个启动场景创建一个全局的LifetimeScope。这个根作用域注册所有的单例服务和全局服务。// 在启动场景的某个 GameObject 上挂载此脚本 public class GameLifetimeScope : LifetimeScope { protected override void Configure(IContainerBuilder builder) { // 1. 注册全局单例 builder.RegisterIAssetProvider, AddressableAssetProvider(Lifetime.Singleton); builder.RegisterIInputService, UnityInputService(Lifetime.Singleton); builder.RegisterGameStateManager(Lifetime.Singleton); // 2. 注册场景中已存在的 MonoBehaviour 实例 builder.RegisterComponentInHierarchyAudioListener(); builder.RegisterComponentInHierarchyCamera(); // 3. 注册接口和其实现 builder.RegisterIPlayerRepository, PlayerPrefsPlayerRepository(Lifetime.Singleton); } }对于每个需要独立生命周期的模块如一个关卡、一个战斗场景我们可以创建一个子作用域。public class LevelSceneScope : LifetimeScope { [SerializeField] private EnemySpawnPoint[] _spawnPoints; // 可序列化引用 protected override void Configure(IContainerBuilder builder) { // 父作用域GameLifetimeScope的服务在这里都可用 // 注册本关卡特有的服务生命周期为 Scoped builder.RegisterLevelManager(Lifetime.Scoped); builder.RegisterIEnemySpawner, WaveEnemySpawner(Lifetime.Scoped) .WithParameter(spawnPoints, _spawnPoints); // 传递参数 // 注册本场景 UI builder.RegisterComponentInHierarchyLevelHUD(); } }当关卡加载时实例化LevelSceneScope它会链接到父作用域。当关卡结束销毁这个GameObject其作用域内所有Scoped生命周期的对象都会被释放非常适合资源管理。4. 实战重构将一个 MonoBehaviour 怪兽拆解理论说再多不如实战。假设我们有一个经典的GameManagerMonoBehaviour它负责游戏状态、分数、UI 更新、场景切换是个典型的“上帝对象”。我们目标是把它拆了。重构前 (GodGameManager.cs):public class GodGameManager : MonoBehaviour { public static GodGameManager Instance; public int Score { get; private set; } public Text scoreText; public GameObject gameOverUI; private Player _player; private EnemySpawner _spawner; private AudioSource _bgmSource; void Awake() { Instance this; } void Start() { _player FindObjectOfTypePlayer(); _spawner FindObjectOfTypeEnemySpawner(); _bgmSource GetComponentAudioSource(); StartGame(); } void StartGame() { Score 0; UpdateScoreUI(); _spawner.StartSpawning(); _bgmSource.Play(); } public void AddScore(int points) { Score points; UpdateScoreUI(); if (Score 1000) WinGame(); } void UpdateScoreUI() { scoreText.text $Score: {Score}; } public void OnPlayerDied() { gameOverUI.SetActive(true); _spawner.StopAllCoroutines(); _bgmSource.Stop(); } void WinGame() { /* ... */ } }重构步骤识别职责定义接口IScoreService: 管理分数。IGameStateService: 管理游戏状态开始、结束、胜利。IAudioService: 管理背景音乐。IPlayerService: 提供玩家信息。IEnemySpawnService: 管理敌人生成。创建领域服务纯 C# 类// ScoreService.cs public interface IScoreService { int CurrentScore { get; } event Actionint OnScoreChanged; void Add(int points); } public class ScoreService : IScoreService { public int CurrentScore { get; private set; } public event Actionint OnScoreChanged; public void Add(int points) { CurrentScore points; OnScoreChanged?.Invoke(CurrentScore); } }创建应用层协调者// GameFlowController.cs - 协调游戏流程 public class GameFlowController { private readonly IGameStateService _gameState; private readonly IEnemySpawnService _spawner; private readonly IAudioService _audioService; public GameFlowController(IGameStateService gameState, IEnemySpawnService spawner, IAudioService audioService) { _gameState gameState; _spawner spawner; _audioService audioService; _gameState.OnGameStarted StartGame; _gameState.OnGameEnded EndGame; } private void StartGame() { _spawner.StartSpawning(); _audioService.PlayBGM(); } private void EndGame(bool isWin) { _spawner.StopSpawning(); _audioService.StopBGM(); } }创建基础设施层实现// UnityAudioService.cs public class UnityAudioService : IAudioService { private readonly AudioSource _bgmSource; public UnityAudioService(AudioSource bgmSource) // 注入具体的 AudioSource { _bgmSource bgmSource; } public void PlayBGM() _bgmSource.Play(); public void StopBGM() _bgmSource.Stop(); }创建薄薄的 MonoBehaviour 视图// GameUI.cs - 只负责UI显示 public class GameUI : MonoBehaviour { [SerializeField] private Text _scoreText; [SerializeField] private GameObject _gameOverPanel; [Inject] private IScoreService _scoreService; [Inject] private IGameStateService _gameState; void Start() { _scoreService.OnScoreChanged UpdateScoreDisplay; _gameState.OnGameEnded ShowGameOver; UpdateScoreDisplay(_scoreService.CurrentScore); } void UpdateScoreDisplay(int score) _scoreText.text $Score: {score}; void ShowGameOver(bool isWin) _gameOverPanel.SetActive(true); } // PlayerHealthView.cs - 监听玩家死亡事件 public class PlayerHealthView : MonoBehaviour { [Inject] private IPlayerService _playerService; [Inject] private IGameStateService _gameState; void Start() { _playerService.OnPlayerDied () _gameState.EndGame(false); } }在 LifetimeScope 中注册所有依赖public class GameSceneScope : LifetimeScope { [SerializeField] private AudioSource _bgmAudioSource; [SerializeField] private GameUI _gameUI; [SerializeField] private Player _player; protected override void Configure(IContainerBuilder builder) { // 注册服务 builder.RegisterScoreService(Lifetime.Singleton).AsIScoreService(); builder.RegisterGameStateService(Lifetime.Singleton).AsIGameStateService(); builder.RegisterUnityAudioService(Lifetime.Singleton).AsIAudioService() .WithParameter(_bgmAudioSource); // 注册协调者 builder.RegisterGameFlowController(Lifetime.Singleton); // 注册已存在于场景中的组件实例 builder.RegisterInstance(_player.GetComponentIPlayerService()); builder.RegisterComponent(_gameUI); builder.RegisterComponent(_player.GetComponentPlayerHealthView()); } }经过这番重构原来的GodGameManager被彻底分解。每个类职责清晰依赖关系明确且都可以独立进行单元测试。比如测试ScoreService你完全不需要启动 Unity直接 new 一个对象调用Add方法验证事件和属性即可。5. 高级技巧与最佳实践掌握了基础一些高级技巧能让你的架构更健壮、开发更高效。5.1 利用 RegisterEntryPoint 自动启动对于需要在游戏启动或场景加载时自动执行的逻辑比如初始化配置、加载数据可以使用RegisterEntryPoint。VContainer 会在所有依赖解析完成后自动调用实现了IStartable或ITickable等接口的对象。public class GameInitializer : IStartable { private readonly IAssetProvider _assetProvider; private readonly IPlayerRepository _playerRepo; public GameInitializer(IAssetProvider assetProvider, IPlayerRepository playerRepo) { _assetProvider assetProvider; _playerRepo playerRepo; } public void Start() { // 游戏启动时自动执行 _assetProvider.WarmUp(); _playerRepo.Load(); Debug.Log(Game Initialized!); } } // 在 LifetimeScope 中注册 builder.RegisterEntryPointGameInitializer();5.2 事件总线与松散耦合通信即使使用了 DI如果服务之间还需要直接互相调用耦合度依然不低。引入一个简单的事件总线Event Bus/Message Broker可以实现完全的解耦。一个服务发布事件其他服务订阅它彼此不知道对方的存在。// 定义事件 public struct EnemyDefeatedEvent { public int Experience; public Vector3 Position; } // 事件总线接口 public interface IEventPublisher { void PublishT(T event) where T : struct; } public interface IEventSubscriber { UniTaskT SubscribeT(ActionT handler) where T : struct; } // VContainer 注册可以使用第三方库如 MessagePipe或自己实现一个简单的 builder.RegisterEventAggregator(Lifetime.Singleton).AsIEventPublisher, IEventSubscriber(); // 发布者 public class CombatSystem { private readonly IEventPublisher _publisher; public void DefeatEnemy(Enemy enemy) { // ... 战斗逻辑 _publisher.Publish(new EnemyDefeatedEvent { Experience enemy.Exp, Position enemy.transform.position }); } } // 订阅者 public class ExperienceSystem : IStartable { private readonly IEventSubscriber _subscriber; private readonly IPlayerLevelService _levelService; private IDisposable _subscription; public ExperienceSystem(IEventSubscriber subscriber, IPlayerLevelService levelService) { _subscriber subscriber; _levelService levelService; } public void Start() { _subscription _subscriber.SubscribeEnemyDefeatedEvent(OnEnemyDefeated); } private void OnEnemyDefeated(EnemyDefeatedEvent evt) { _levelService.AddExperience(evt.Experience); } }5.3 与 UniTask、Addressables 等流行库集成VContainer与现代 Unity 开发栈配合得很好。例如你可以轻松注入UniTask的CancellationTokenSource或者封装Addressables的加载接口。// 注册一个全局的 CancellationTokenSource用于协同取消任务 builder.RegisterCancellationTokenSource(Lifetime.Singleton).WithParameter(typeof(bool), false); // 封装 Addressables public interface IAssetLoaderT where T : UnityEngine.Object { UniTaskT LoadAsync(string key, CancellationToken ct default); void Release(T asset); } public class AddressablesAssetLoaderT : IAssetLoaderT where T : UnityEngine.Object { public async UniTaskT LoadAsync(string key, CancellationToken ct) { var handle Addressables.LoadAssetAsyncT(key); await handle.WithCancellation(ct); return handle.Result; } public void Release(T asset) Addressables.Release(asset); } // 注册泛型接口需要一点技巧 builder.Register(typeof(AddressablesAssetLoader), Lifetime.Scoped).As(typeof(IAssetLoader));5.4 针对 UI 的优化注册对于 UI尤其是动态生成的 UI 项如列表中的物品可以使用Factory模式。VContainer 提供了IFactoryT接口可以自动生成工厂。// 定义UI项 public class InventoryItemView : MonoBehaviour { [Inject] public void Construct(ItemData data, IInventoryService inventory) { /* 初始化 */ } } // 注册工厂 builder.RegisterFactoryItemData, InventoryItemView((resolver, data) { var prefab resolver.ResolveIAssetLoaderGameObject().LoadAsync(InventoryItemPrefab).Result; var instance Instantiate(prefab); resolver.InjectGameObject(instance); // 关键向实例注入依赖 instance.GetComponentInventoryItemView().Construct(data, resolver.ResolveIInventoryService()); return instance; }, Lifetime.Scoped); // 使用工厂 public class InventoryUI : MonoBehaviour { [Inject] private IFactoryItemData, InventoryItemView _itemFactory; public void AddItem(ItemData data) { var itemView _itemFactory.Create(data); itemView.transform.SetParent(this.transform, false); } }6. 常见问题、性能考量与排查技巧迁移到新架构不会一帆风顺这里记录了一些常见的坑和解决方案。6.1 循环依赖问题这是 DI 框架最常见的问题。A 依赖 BB 又依赖 A容器无法解析。VContainer 会抛出清晰的异常。解决方案重构设计检查循环依赖是否合理。通常意味着两个类职责划分不清可以考虑提取公共逻辑到第三个类中或者使用事件进行单向通信。属性注入如果循环依赖确实必要但应尽量避免可以将其中一个依赖改为属性注入并使用[Inject]特性。但这只是权宜之计。延迟解析注入FuncB或LazyB而不是B本身。这样在 A 中需要 B 的时候才去解析。public class A { private readonly FuncB _bFactory; public A(FuncB bFactory) { _bFactory bFactory; } public void DoSomething() { var b _bFactory.Invoke(); /* 使用 b */ } } // 注册时无需特殊处理VContainer 自动支持 FuncT。6.2 与 Unity 生命周期和协程的协作纯 C# 服务里没有MonoBehaviour自然也就没有StartCoroutine。如何处理异步和延时操作使用 UniTask这是目前最推荐的方式。UniTask几乎可以替代所有协程场景且性能更好与 async/await 语法完美结合。在你的纯 C# 服务中可以直接使用UniTask.Delay、UniTask.NextFrame等。注入 MonoBehaviour 代理如果必须使用协程例如某些插件只提供了协程接口可以创建一个薄的MonoBehaviour代理服务。public interface ICoroutineRunner { Coroutine StartCoroutine(IEnumerator routine); void StopCoroutine(Coroutine routine); } public class MonoBehaviourCoroutineRunner : MonoBehaviour, ICoroutineRunner { // 实现接口方法就是 MonoBehaviour 原生的 StartCoroutine 和 StopCoroutine } // 在场景中创建一个 GameObject 挂载此脚本并在 LifetimeScope 中注册它。 builder.RegisterComponentInNewGameObjectMonoBehaviourCoroutineRunner(Lifetime.Singleton).AsICoroutineRunner(); // 然后在服务中注入 ICoroutineRunner 并使用。6.3 性能考量与优化依赖注入框架在启动时会有一个“注册”和“构建容器”的开销但这是在加载时一次性完成的。在运行时依赖解析Resolve的速度极快通常可以忽略不计。但以下几点需要注意避免在 Update 中频繁解析绝对不要在Update里调用Resolve。所有依赖都应在对象构造时或初始化阶段注入完成。谨慎使用Resolve尽量使用构造函数注入。显式调用Resolve是服务定位器模式应尽量避免因为它隐藏了依赖。作用域管理合理使用Scoped生命周期。对于关卡内的对象使用作用域关卡结束即释放可以有效防止内存泄漏。预生成代码可选对于超大型项目VContainer 支持通过 Roslyn 源代码生成器来生成部分依赖解析代码以进一步提升启动性能。这属于进阶优化多数项目不需要。6.4 调试与日志当依赖注入出错时VContainer 的异常信息通常很详细会告诉你哪个类型无法解析以及它的依赖链。此外你可以在注册时开启日志查看容器的构建过程。// 在构建容器时添加日志 var containerBuilder new ContainerBuilder(); containerBuilder.RegisterMyService(Lifetime.Singleton); // ... 其他注册 #if DEBUG containerBuilder.RegisterBuildCallback(container { var diagnostics container.Diagnostics; // 可以将 diagnostics 输出到控制台或文件 Debug.Log(diagnostics); }); #endif var container containerBuilder.Build();6.5 单元测试变得极其简单这是依赖注入带来的最大好处之一。现在你可以轻松地为纯 C# 的业务逻辑类编写单元测试。// 测试 ScoreService [Test] public void AddScore_ShouldIncreaseCurrentScore_AndRaiseEvent() { // 1. 准备 (Arrange) var scoreService new ScoreService(); int eventRaisedScore 0; scoreService.OnScoreChanged (score) eventRaisedScore score; // 2. 执行 (Act) scoreService.Add(100); // 3. 断言 (Assert) Assert.AreEqual(100, scoreService.CurrentScore); Assert.AreEqual(100, eventRaisedScore); } // 测试依赖注入的类使用 Mock 框架如 NSubstitute, Moq [Test] public void PlayerAttackService_ShouldCallWeaponAndEnemyManager() { // 1. 准备 Mock 对象 var mockWeapon Substitute.ForIWeapon(); var mockEnemyManager Substitute.ForIEnemyManager(); var mockEnemy Substitute.ForIEnemy(); mockWeapon.CanAttack().Returns(true); mockEnemyManager.GetNearestEnemy(Arg.AnyVector3()).Returns(mockEnemy); // 2. 创建被测试对象注入 Mock var attackService new PlayerAttackService(mockEnemyManager, mockWeapon, ...); // 3. 执行 attackService.ExecuteAttack(Vector3.zero); // 4. 验证 Mock 对象是否被以预期的方式调用 mockWeapon.Received(1).CanAttack(); mockEnemy.Received(1).TakeDamage(Arg.AnyDamageInfo()); mockWeapon.Received(1).Cooldown(); }这种测试无法在传统的、严重依赖MonoBehaviour和UnityEngineAPI 的代码中实现。现在你的核心业务逻辑可以拥有高覆盖率的单元测试这是代码质量最坚实的保障。迁移到 VContainer 和依赖注入架构初期会有一定的学习成本和重构工作量但从中长期来看它对项目可维护性、可测试性和团队协作效率的提升是巨大的。它迫使你思考代码的职责和边界最终得到的是一个更清晰、更健壮、更能应对需求变化的代码基。