在接口内部定义并实现该接口的类/对象为何可行？

嘿，这个问题问得特别戳中初学者的疑惑点！一开始看到这种写法确实会有种“递归套娃”的错觉，但其实背后是Kotlin（以及JVM语言通用的）类加载和嵌套类型规则在起作用，完全不是什么魔法～

咱们一步步拆解来看：

首先，编译器处理代码的顺序是关键：

• 当它读到sealed interface MarsUiState这一行时，会先确立这个接口的类型存在——也就是说，MarsUiState作为一个抽象类型的名称和结构（虽然它的内部成员还没处理完）已经可以被引用了。
• 接下来才会处理接口内部的嵌套类型：Success数据类、Error和Loading对象。这时候它们声明实现MarsUiState，完全是基于已经存在的接口类型，不存在“接口还没创建完就被内部类引用”的问题。

你担心的“类需要接口先存在”其实完全没错，但这里的接口确实已经先被编译器识别了——嵌套类型只是在外部接口的作用域内定义，并不依赖接口的“完全初始化”（毕竟接口本身是抽象的，不需要实例化，只要类型存在就行）。

另外，这种写法其实正是Kotlin密封接口的标准用法：把所有可能的实现都封装在接口内部，确保外部无法新增其他实现，完美适配UI状态这种有限的状态场景（成功、错误、加载三种情况），让状态处理的代码更严谨、更易维护。

举个生活化的类比：就像你先准备了一个标着“MarsUI状态”的文件夹（接口），然后在这个文件夹里放三个文件：“成功状态”“错误状态”“加载状态”，每个文件都明确标注“属于MarsUI状态文件夹”——文件夹先存在，文件才放进去，逻辑完全通顺，根本不是什么递归魔术～

咱们再把你贴的代码用代码块标出来更清晰：

sealed interface MarsUiState {
    data class Success(val photos: List<MarsPhoto>) : MarsUiState
    object Error : MarsUiState
    object Loading : MarsUiState
}

这里的每个内部类型都是MarsUiState的合法实现，因为接口类型在它们定义之前就已经存在了。

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