Dagger2在ViewModel中进行字段注入是否存在问题？

你提到的这种在ViewModel的init方法里直接调用全局组件inject的实现方式，虽然技术上能正常运行，但存在不少严重问题：

核心问题点 #

• 破坏ViewModel的独立性与生命周期设计：ViewModel的核心作用是在配置变更（如屏幕旋转）时保留实例、隔离业务逻辑，但这种写法让ViewModel强耦合到全局的App.appComponent。一旦全局组件的实现调整，ViewModel也得跟着修改，完全失去了本该具备的业务独立性。
• 违背依赖注入的核心原则：依赖注入的本质是让类被动接收依赖，而非主动获取。你这种写法相当于ViewModel自己主动拉取依赖，把注入逻辑硬编码在类内部，既不符合控制反转思想，也大幅降低了代码可维护性——后续要修改依赖来源，必须直接改动ViewModel代码。
• 测试成本陡增：做单元测试时，通常需要给ViewModel替换Mock依赖（比如假的MyRepository），但因为ViewModel直接绑定了全局App.appComponent，你要么得专门搭建一套Dagger测试组件，要么只能用反射修改lateinit变量，这两种方式都让测试变得繁琐且不优雅。
• 无法适配复杂依赖场景：如果后续ViewModel需要更多依赖，你只能继续依赖全局组件提供所有实例，这会导致AppComponent职责越来越杂，最终变成大而全的“上帝组件”，违背单一职责原则。

推荐写法对比 #

官方推荐的ViewModelFactory注入方式，是让ViewModel通过构造函数接收依赖，由Factory从Dagger组件中获取实例并传入：

// ViewModel类：只关注业务，完全不依赖Dagger
class MainActivityViewModel(
    val repository: MyRepository
) : ViewModel() {
    // 业务逻辑实现...
}

// ViewModelFactory：负责从Dagger获取依赖并创建ViewModel实例
class MainViewModelFactory @Inject constructor(
    private val repository: MyRepository
) : ViewModelProvider.Factory {
    override fun <T : ViewModel> create(modelClass: Class<T>): T {
        return MainActivityViewModel(repository) as T
    }
}

// 在Activity/Fragment中获取ViewModel
val viewModel = ViewModelProvider(this, viewModelFactory)[MainActivityViewModel::class.java]

这种写法下，ViewModel完全与Dagger解耦，测试时直接传入Mock依赖即可，代码结构清晰且符合设计原则。

内容的提问来源于stack exchange，提问作者Mayur Salvi