为何Moshi Codegen要求@JsonClass仅标注在具体类上？

Moshi不支持直接为接口或抽象类生成JSON适配器，核心原因在于反序列化的本质需求与接口/抽象类的特性冲突：

• 实例化限制：接口和抽象类无法直接实例化，反序列化的核心是将JSON数据映射为具体对象实例，Moshi无法确定应该创建哪个具体实现类的实例来承载数据。
• 字段歧义风险：多个接口组合时可能出现同名字段，Moshi无法判断这些字段的优先级或合并规则，容易引发序列化/反序列化的行为歧义。
• 类型明确性设计：Moshi的设计原则强调类型的明确性，反序列化需要明确的目标类型来确保数据映射的准确性，而接口属于抽象类型，无法提供这种明确性。

针对你遇到的不同REST端点返回不同结构食谱的场景，可以通过以下方式避免字段重复：

1. 委托模式复用字段定义 #

利用Kotlin的委托特性，将基础字段的实现委托给基础数据类，组合出不同的接口实现类：

// 基础接口定义不变
interface Recipe {
  val id: Int
  val name: String
}

interface HasIngredients {
  val ingredients: List<String>
}

interface HasAuthor {
  val author: String
}

// 基础实现类
data class BaseRecipe(override val id: Int, override val name: String) : Recipe
data class WithAuthor(override val author: String) : HasAuthor
data class WithIngredients(override val ingredients: List<String>) : HasIngredients

// 组合类，通过委托复用实现
class DetailedRecipe(
    private val recipe: Recipe,
    private val author: HasAuthor,
    private val ingredients: HasIngredients
) : Recipe by recipe, HasAuthor by author, HasIngredients by ingredients

class SearchResultRecipe(
    private val recipe: Recipe,
    private val author: HasAuthor
) : Recipe by recipe, HasAuthor by author

然后为这些组合类生成Moshi适配器即可，这样既避免了字段重复，又满足了Moshi对具体类型的要求。

2. 数据类直接实现多接口 #

如果字段数量不多，也可以直接让数据类实现多个接口，Kotlin的数据类语法简洁，实际维护成本并不高：

data class DetailedRecipe(
    override val id: Int,
    override val name: String,
    override val author: String,
    override val ingredients: List<String>
) : Recipe, HasAuthor, HasIngredients

data class SearchResultRecipe(
    override val id: Int,
    override val name: String,
    override val author: String
) : Recipe, HasAuthor

这种方式更直接，Moshi可以轻松为这些数据类生成适配器，且代码可读性更高。

3. 自定义JsonAdapter处理复杂场景 #

如果上述方式都不满足需求，可以编写自定义JsonAdapter，手动处理接口类型的反序列化逻辑，根据JSON中的字段判断应该映射到哪种接口组合的实现类。不过这种方式需要编写更多自定义代码，适合复杂场景。

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