熔点：十道题，和你不知道自己不知道的

data class User(val id: String) {
    val tag: String = "default"    // 写在类体里，不在主构造
}

User("a").also { it }  == User("a")   // ?

答案：不会—— equals、hashCode、toString、copy、componentN 只认主构造函数里的属性。写在类体里的 val tag 对它们完全隐形。

这条规则在两个地方咬人：一是把某个字段挪出主构造去做「计算属性」时，相等性语义悄悄变了；二是反过来 —— 你在主构造里塞了一个 createdAt: Instant，于是两个逻辑上相同的对象因为时间戳不同而 !=，然后你的 distinct()、Set、LazyColumn 的 key 全部开始表演。

去第 02 章，反编译看它到底生成了什么。

fun f(s: String?) {
    if (s != null) println(s.length)     // ✓ 编译通过
}

class C {
    var s: String? = null
    fun g() {
        if (s != null) println(s.length)  // ✗ 编译错误
    }
}

答案：因为 s 是可变属性（var），编译器不敢假设它在两行之间没被改掉。别的线程可能改它，甚至一个自定义 getter 每次调用都能返回不同的值 —— 编译器要的是证明，不是「大概率没问题」。

局部变量为什么可以？因为编译器能看见它的全部生命周期，能证明中间没人动过它。

去第 04 章 —— 顺便学会用 contract 亲手教编译器认你自己写的判空函数。

open class Animal
class Dog : Animal()

fun Animal.name() = "animal"
fun Dog.name() = "dog"

val pet: Animal = Dog()
println(pet.name())   // ?

答案：animal。因为扩展函数是静态方法，按变量的静态类型分派，不参与多态。pet 的静态类型是 Animal，于是叫到了 Animal.name() —— 哪怕它运行时装的是一条狗。

推论还有两条：成员函数永远赢过同名扩展函数（所以给第三方类加扩展，哪天它自己加了同名方法，你的扩展就悄无声息地失效了）；扩展函数访问不了 private 成员，因为它压根不在那个类里。

去第 10 章。

class Api {
    companion object {
        fun create() = Api()
    }
}

答案：不是 static。它编译成一个名为 Companion 的嵌套类的单例实例。Java 侧必须写 Api.Companion.create()，而且每次调用要多走一跳。

想要真 static：函数加 @JvmStatic，常量用 const val（只有它才会被编译成 Java 的 static final 并内联进调用方 —— 这也意味着改了 const 的值必须重新编译所有调用方）。

去第 02 章。

@JvmInline
value class UserId(val raw: String)

fun a(id: UserId) { }              // 1
fun b(id: UserId?) { }             // 2
fun c(ids: List<UserId>) { }       // 3
fun d(): UserId = UserId("x")      // 4
fun e(any: Any) { }; e(UserId("x")) // 5

答案：2、3、5 会装箱；1、4 不会。规则是：直接当参数/返回值用 → 编译后就是底层类型（String），零分配；一旦它出现在可空位置、泛型实参、集合元素、或者被当作 Any/接口传递，编译器就必须造一个真对象把它包起来。

这条边界很多人不知道，于是在热路径上用 List<UserId> 或者 UserId?，以为零开销，其实每个元素都在分配。

去第 06 章。

fun feed(animals: List<Animal>) { }
fun feedM(animals: MutableList<Animal>) { }

val dogs: MutableList<Dog> = mutableListOf()
feed(dogs)     // ?
feedM(dogs)    // ?

答案：feed(dogs) 可以，feedM(dogs) 不行。因为 List<out E> 声明了协变 —— 它只往外生产 E，从不接收 E，所以「一个只会交出狗的列表」当然可以当「只会交出动物的列表」用。

而 MutableList<E> 是不变的：它既能读又能写。一旦允许 MutableList<Dog> 当 MutableList<Animal> 用，我就能往你的狗列表里 add(Cat()) —— 类型系统必须在编译期堵死这条路。

一句口诀：只生产用 out，只消费用 in，又读又写只能不变。 去第 05 章。

viewModelScope.launch {
    try {
        val d = async { error("boom") }   // 立刻就炸了
    } catch (e: Exception) {
        Log.e("x", "caught")              // 会打印吗？
    }
}

答案：抓不到，而且整个 scope 会被取消。两件事同时在发生：

① async 的异常被存进 Deferred 里，等到 await() 才抛 —— 你从没 await，所以 catch 块永远等不到它；②但 async 创建的是 viewModelScope 的子协程，子协程失败会向上传播到父 Job，于是父作用域连同它所有的兄弟协程一起被取消。try/catch 拦不住这条传播路径 —— 它走的是 Job 树，不是调用栈。

这是协程里最反直觉的一课。去第 17 章（以及第 15 章的 Job 树）。

答案：一个是「不启动」，一个是「启动了再杀掉」。

conflate()：下游忙的时候，新值直接覆盖队列里那个还没被取走的旧值。下游处理完当前这个，拿到的是最新值，中间的被丢弃 —— 但已经在处理的那个会跑完。

collectLatest：新值一到，正在执行的收集块立刻被取消（在下一个挂起点），然后用新值重启。所以前面那些跑到一半的工作会被中断。

差别在什么时候致命？如果你的收集块里写了数据库或发了埋点，collectLatest 会给你留下半截的副作用。而如果你要的是「搜索框每敲一个字就作废上一次请求」，它正是你要的东西。

去第 18 章，弹珠台上放一遍就全懂了。

val state = repo.flow
    .stateIn(viewModelScope, SharingStarted.WhileSubscribed(5000), Loading)

答案：在等屏幕旋转（以及任何短暂的重建）。

WhileSubscribed 的意思是「有订阅者时才启动上游，最后一个订阅者走了就停」。但 Android 的配置变更会让 UI 层短暂地全部取消订阅、然后立刻重新订阅。如果停止是立刻的，上游会被停掉又重启 —— 数据库重新查、网络重新请求，白白浪费。

那个 5000ms 就是宽限期：最后一个订阅者离开后再等 5 秒，如果这期间有人回来（旋转屏幕重建完成），上游就从没停过。而如果用户真的离开了页面，5 秒后上游干净地停掉。

顺带一问：你知道 stateIn 和 shareIn 的区别吗？去第 19 章。

suspend fun load(): Data? = runCatching {
    api.fetch()          // 一个 suspend 函数
}.getOrNull()

答案：它会吞掉协程的取消信号。

协程的取消是靠抛出 CancellationException 实现的。而 runCatching 抓的是 Throwable —— 它把取消异常也一并抓走，然后 getOrNull() 返回 null，协程假装什么都没发生地继续往下跑。

后果：你的协程「取消不掉」。页面已经销毁了，它还在往下走，甚至把结果写回一个已经死掉的 View。这个 bug 极难查，因为它只在「用户快速退出」时偶发。

正确写法是自己 catch 并重新抛出取消异常，或者干脆别在 suspend 代码里用 runCatching：

try {
    api.fetch()
} catch (e: CancellationException) {
    throw e                    // 取消必须放行
} catch (e: Exception) {
    null
}

去第 20 章。