Kotlin注入AuthDataModel至认证ViewModel报错：仅允许一个@Inject构造函数

问题根源 #

你碰到的这个编译错误，核心原因是Kotlin数据类的自动构造函数生成特性和依赖注入框架的规则冲突了。

看你提供的代码：

data class AuthDataModel @Inject constructor( 
    var username: String = "", 
    var password: String = "", 
    var mobileData: String = ""
)

因为你给主构造函数的参数都加了默认值，Kotlin编译器会自动帮你生成一个无参构造函数。而你又给主构造函数标注了@Inject，这就导致依赖注入框架（比如Dagger/Hilt）认为这个类有两个带@Inject的构造函数——你写的主构造函数，加上自动生成的无参构造函数，直接违反了「一个类只能有一个@Inject构造函数」的规则。

可行的解决方案 #

根据你的使用场景，这里有几个不同的修复方向：

1. 移除参数默认值（最稳妥）

如果AuthDataModel必须通过依赖注入创建，而且你不需要无参的实例，那直接去掉参数的默认值就好：

data class AuthDataModel @Inject constructor( 
    var username: String, 
    var password: String, 
    var mobileData: String
)

这样编译器不会生成额外的构造函数，框架只会看到一个带@Inject的主构造函数，错误自然就消失了。不过要记得注入时必须提供这三个参数的实例哦。

2. 保留默认值，用@JvmOverloads限定注入构造函数

如果你需要保留默认值，同时让框架只识别你标注的主构造函数，可以加上@JvmOverloads注解：

data class AuthDataModel @Inject @JvmOverloads constructor( 
    var username: String = "", 
    var password: String = "", 
    var mobileData: String = ""
)

@JvmOverloads会让编译器生成重载构造函数，但只有你标注了@Inject的主构造函数会被框架识别。不过要注意，部分依赖注入框架对这种方式的支持可能有限，比如Dagger在处理带默认值的构造函数时可能需要额外配置，所以这个方案不如第一个稳妥。

3. 放弃注入数据类（更符合数据类设计）

其实啊，数据类本质是用来承载数据的DTO（数据传输对象），通常不需要依赖注入。如果你的AuthDataModel只是用来存认证相关的数据，完全可以去掉@Inject，在ViewModel里直接创建实例：

data class AuthDataModel( 
    var username: String = "", 
    var password: String = "", 
    var mobileData: String = ""
)

// 在ViewModel里直接使用
class AuthViewModel : ViewModel() {
    private val authData = AuthDataModel()
}

这种方式更符合数据类的设计初衷，也避免了依赖注入的不必要麻烦。

总结 #

• 错误本质是Kotlin自动生成的构造函数和你标注的@Inject构造函数冲突
• 如果不需要注入数据类，直接去掉@Inject是最简单的解决办法
• 如果必须注入，优先考虑移除参数默认值；非要保留默认值的话，再尝试@JvmOverloads方案

内容的提问来源于stack exchange，提问作者Hrant Nurijanyan