sealed + when：让非法状态无法表示

先数一数你的鬼状态

这台机器会枚举出所有组合，把「业务承认的」和「鬼状态」标出来。勾上你自己 UiState 里真实有的字段，看看数字：

五个字段 = 32 种可表示状态，业务只要 4 种。28 个鬼状态。它们的代价体现在三个地方：

• UI 层的防御性代码：if (isLoading && !hasError)、data?.takeIf { !isLoading } —— 每一处都是在手工排除本不该存在的状态。
• 永远写不完的测试：你测了 4 种正常路径，那 28 种呢？
• 最贵的那种 bug：某次异步回调把 isLoading 置回 false 但忘了清 errorMsg，于是用户看到一个转圈的加载页叠着一个错误提示。而这在类型层面是完全合法的。

解法：和类型

问题的根源是你在用积类型（product type）建模一个和类型（sum type）的东西。

• 积类型 = 「而且」：data class 就是积 —— 一个 User 同时有 name 而且有 age。状态数是乘起来的（2 × 2 × 2 × 2 = 16）。
• 和类型 = 「或者」：sealed 就是和 —— 一个 UiState 要么是 Loading 要么是 Success。状态数是加起来的（1 + 1 + 1 + 1 = 4）。

UI 状态天生是「或者」，你却用「而且」去表示它 —— 于是多出来的全是垃圾。换成和类型：

sealed interface UiState {
    data object Loading : UiState
    data class  Success(val items: List<Item>) : UiState   // 数据只住在这里
    data object Empty : UiState
    data class  Error(val msg: String) : UiState            // 错误只住在这里
}

注意那两句注释 —— 这是最关键的一条军规：

穷尽检查：Kotlin 白送你的编译期覆盖率

fun render(state: UiState) = when (state) {   // 少写一个分支 → 编译错误
    Loading    -> spinner()
    is Success -> list(state.items)     // 这里 items 不可能是 null
    Empty      -> emptyView()
    is Error   -> toast(state.msg)
}

三个月后产品说「加一个 Refreshing 状态」。你在 sealed 里加一个子类型 —— 然后编译器立刻在整个项目里把所有需要处理它的地方标红。

这就是 sealed 的真正价值：它不是「更优雅的写法」，它是一个会在未来替你干活的机器人。加一个状态，编译器就把所有遗漏的地方交给你。这在动辄几十个 UI 分支的大项目里，是救命的。

when (state) {
    is Success -> render(state.items)
    else -> spinner()      // ← 你亲手关掉了穷尽检查
}

一个历史遗留的细节

老 Kotlin 里有个坑：只有 when 表达式（结果被赋值或返回）才做穷尽检查，when 语句不做。于是这段代码在几年前是合法的：

when (state) {          // 当语句用：老版本里不检查穷尽！
    Loading -> spinner()
    is Error -> toast(state.msg)
    // 漏了 Success 和 Empty，编译器一句话没有
}

好消息：这个坑已经填了。从 Kotlin 1.7 起，对 sealed / enum / Boolean 的 when 语句不穷尽也是编译错误。但如果你的团队里还有人抱着「when 一定要写成表达式才安全」的老经验 —— 那条经验现在只是风格建议了（当然它依然是好风格：表达式形态更难写出遗漏的副作用）。

// 2.1 之前
when (state) {
    is Success -> if (state.items.isEmpty()) showEmpty()   // 嵌套 if，逻辑藏起来了
                  else showList(state.items)
    ...
}

// 2.1 起：在 is 分支后面直接挂守卫
when (state) {
    is Success if state.items.isEmpty() -> showEmpty()
    is Success                          -> showList(state.items)
    is Error   if state.isRetryable     -> retry()
    is Error                            -> toast(state.msg)
    Loading                             -> spinner()
}

when (state) {
    Loading -> spinner()          // 不用再写 UiState.Loading
    is Success -> ...
}

sealed class 还是 sealed interface？

默认用 sealed interface。理由：

• 它允许多重继承。一个类型可以同时属于两个 sealed 层级 —— 比如 NetworkError 既是 FetchError 又是 Retryable。用 sealed class（单继承）就做不到。
• 它不带构造函数和状态，更干净。

什么时候用 sealed class？当所有子类型确实共享状态时（比如所有的 Error 都有一个 timestamp）—— 但即使这种情况，通常也可以用接口里的抽象 val 解决。

顺带两个语法点：

• data object（1.9 起）：没有数据的状态用它，白送一个好看的 toString()（Loading 而不是 com.foo.UiState$Loading@3f2a1b）和正确的 equals。别再用 object 了。
• sealed 的封闭范围：子类型必须和父类型在同一个模块、同一个包里（1.5 起放宽到这个粒度，以前必须在同一文件）。这就是「sealed（密封）」的含义 —— 编译器能看全所有可能，才敢做穷尽检查。

sealed vs enum：什么时候用哪个

判据一句话：分支之间需要带不同的数据吗？需要 → sealed；不需要 → enum。

落到你的项目里

Android 上，这套建模有三个立刻能用的落点：

① UI 状态（上面讲的）。② 用户意图 / 事件：

sealed interface Intent {
    data class Search(val q: String) : Intent
    data object Refresh : Intent
    data class Delete(val id: ItemId) : Intent
}

// reducer 是一个纯函数，穷尽 when 保证你处理了每一种意图
fun reduce(state: UiState, intent: Intent): UiState = when (intent) { ... }

如果你在用 MVI 或者 Compose 的 state hoisting —— 恭喜，你已经在这个模式里了。sealed 给它上了编译器的保险。

③ 错误：sealed interface FetchError —— 让「这个函数会怎么失败」写在类型里，而不是藏在文档里。这是第 20 章的正题。

sealed interface UiState permits Loading, Success, Error {}
record Success(List<Item> items) implements UiState {}
record Error(String msg) implements UiState {}

String render(UiState s) {
    return switch (s) {                        // 穷尽检查 ✓
        case Success v when v.items().isEmpty() -> "empty";   // 守卫 ✓
        case Success v -> list(v.items());
        case Error e   -> toast(e.msg());
        case Loading l -> "spinner";
    };
}

下一章是熔炼炉的最后一站：by —— 那个你只用过 by lazy 的关键字，其实是 Kotlin 最被低估的扩展点。