Dagger Hilt中@Inject lateinit var与@Inject constructor的选型疑问：为何多数示例采用构造注入？

这个问题问得特别好！很多刚接触Hilt的开发者都会有这个疑惑——明明字段注入看起来更简单，为啥大部分示例都死磕构造注入？咱们来拆解一下背后的原因：

一、构造注入的核心优势 #

1. 依赖可见性与不可变性 #

构造注入把类的所有依赖都明确写在构造函数里，类的使用者一眼就能清楚这个类需要什么才能正常工作。而且注入的依赖可以用val修饰，保证实例化后依赖不会被意外修改，从根源上避免了可变依赖带来的潜在Bug。

反观字段注入，依赖是隐藏在类内部的lateinit var，外部调用者看不到类的依赖清单，而且因为是var类型，存在被误修改的风险，后续排查问题会非常麻烦。

2. 彻底避免未初始化风险 #

用@Inject lateinit var时，如果Hilt还没完成注入就调用该字段，会直接抛出UninitializedPropertyAccessException。虽然@AndroidEntryPoint会在Android组件的生命周期节点自动完成注入，但如果是你自定义的类（比如示例中的CustomClass），要是在非Android组件场景下使用，忘记手动触发注入逻辑，就很容易踩坑。

而构造注入在类实例化的那一刻，所有依赖就已经准备就绪，完全不存在“依赖未初始化”的问题，代码的安全性更高。

3. 测试友好性拉满 #

写单元测试时，构造注入的类可以直接手动传入Mock依赖，比如：

val mockRepository = mock(Repository::class.java)
val customClass = CustomClass(mockRepository, "testName")

整个过程简洁直接，不需要依赖任何注入框架。

但字段注入的类，你得先实例化，再通过反射设置私有字段，或者手动调用Hilt的注入逻辑，测试步骤繁琐，还容易因为注入时机问题导致测试失败。

4. 符合依赖注入的核心原则 #

依赖注入的核心是控制反转和依赖倒置，构造注入让类本身只关注自己的业务逻辑，不需要关心依赖从何而来——类只是声明“我需要这些东西”，获取和注入的工作交给Hilt完成，类与注入框架的耦合度极低。

而字段注入的类必须依赖Hilt的注入机制才能完成初始化，耦合度更高，违背了依赖注入“解耦”的初衷。

二、字段注入的适用场景 #

不是说字段注入一无是处，Hilt官方也明确推荐：只有在无法使用构造注入的Android系统组件（比如Activity、Fragment、View等，这些类的实例由系统创建，我们无法自定义构造函数）中，才使用字段注入。对于你自己编写的业务类、工具类，优先选择构造注入。

三、关于AssistedInject的“模板代码” #

你提到的AssistedInject确实会增加一些模板代码，但这是兼顾“依赖注入”和“手动传参”的规范方案。它把混合依赖的处理逻辑标准化了，比你自己手动去协调注入依赖和手动参数要可靠得多，而且Hilt已经帮我们封装了大部分复杂逻辑，模板代码只是很小的代价。

总结 #

字段注入是“简单但有隐患”的快捷方案，构造注入是“规范且健壮”的最佳实践。大部分示例优先展示构造注入，本质是为了引导开发者养成良好的编码习惯，从根源上写出更可靠、更易维护的代码。

备注：内容来源于stack exchange，提问作者NullPointerException