智能转换与 contracts：编译器为什么不敢转

一条原理，解释全部

智能转换的规则可以背，但没必要。只要记住编译器的原则：

拿这条原理去过一遍所有情况，你会发现每一条都自然成立：

看出来了吗 —— 能转的都是「编译器能证明它是一块死存储」的，不能转的都是「它其实是个函数调用」的。Kotlin 的属性可以是字段，也可以是伪装成字段的函数（第 2 章的推论二），而智能转换只对前者有效。

三种解法，按优先级排

撞上「不能智能转换」时，别急着 !!。按这个顺序试：

① 先把它捞成局部 val（最常用）

class VM {
    var user: User? = null

    fun render() {
        val u = user ?: return       // 捞出来，钉死
        println(u.name)              // 之后全程智能转换，且线程安全
        println(u.age)               // 就算别人改了 this.user，u 还是原来那个
    }
}

这不只是「绕开编译器」—— 它真的更正确。捞成局部变量之后，你的函数在整个执行期间看到的是同一个快照，而不是一个可能中途变脸的属性。编译器的报错其实是在提醒你一个真实的并发风险，它比你更认真。

② ?.let（适合单个表达式）

user?.let { u ->
    render(u.name)     // it / u 是局部的，天然可智能转换
}

注意它和 ① 的区别：?.let 是表达式，能接着往下链；而 ?: return 是提前退出，剩下的代码不用缩进。函数里有一长串逻辑时，① 更好读；只是想「有值就做一件事」，② 更贴切（这正是第 10 章决策树的判据）。

③ when (val x = expr)（分派时）

when (val state = viewModel.state) {   // 在 when 头上捞成 val
    is Success -> render(state.data)   // 智能转换生效
    is Error   -> toast(state.msg)
    Loading    -> spinner()
}

这个写法应该成为你的默认习惯：只要 when 的主语是个属性或函数调用，就用 when (val x = ...)。既拿到智能转换，又避免了重复求值。

教编译器：contracts

现在来到本章真正有意思的部分。看这段代码：

fun String?.isNotNullOrBlank(): Boolean = this != null && this.isNotBlank()

fun greet(name: String?) {
    if (name.isNotNullOrBlank()) {
        println(name.length)      // ✗ 编译错误：name 仍然是 String?
    }
}

你和编译器都知道，走进 if 里面 name 一定不是 null。但编译器看不进函数体 —— 对它来说 isNotNullOrBlank() 只是一个返回 Boolean 的黑盒。

奇怪的是，标准库的 isNullOrBlank() 就能触发智能转换：

if (!name.isNullOrBlank()) {
    println(name.length)          // ✓ 这个居然能转！
}

凭什么它可以？因为它带了一份合同（contract） —— 一份写给编译器的、关于「这个函数会做什么」的声明。你也可以写：

import kotlin.contracts.*

@OptIn(ExperimentalContracts::class)
fun String?.isNotNullOrBlank(): Boolean {
    contract {
        // 「如果我返回 true，那么 this 一定不是 null」
        returns(true) implies (this@isNotNullOrBlank != null)
    }
    return this != null && this.isNotBlank()
}

fun greet(name: String?) {
    if (name.isNotNullOrBlank()) {
        println(name.length)      // ✓ 现在可以了
    }
}

contract { } 块不参与运行时（它会被编译器擦掉），它唯一的作用是向数据流分析器传达一条你保证成立的事实。

fun String?.lie(): Boolean {
    contract { returns(true) implies (this@lie != null) }
    return true          // 撒谎：返回 true 但 this 可能是 null
}

if (name.lie()) println(name.length)   // 编译通过 → 运行时 NPE

另一种合同：callsInPlace

contracts 的第二种形态解决的是另一个问题。先看这段为什么不能编译：

fun myRun(block: () -> Unit) { block() }

fun f() {
    val x: Int
    myRun { x = 1 }      // ✗ 报错：captured member values initialization is forbidden
    println(x)           // ✗ 报错：x 可能未初始化
}

编译器的顾虑：myRun 可能一次都不调用 block（那 x 就没被赋值），也可能调用两次（那 val x 就被赋值了两次，违反了 val 的定义）。它不知道，所以只能全部拒绝。

而标准库的 run、let、apply 都能这么用：

val x: Int
run { x = 1 }      // ✓ 完全合法
println(x)         // ✓ 编译器知道 x 一定被初始化了一次

秘密还是合同：

@OptIn(ExperimentalContracts::class)
inline fun myRun(block: () -> Unit) {
    contract {
        callsInPlace(block, InvocationKind.EXACTLY_ONCE)   // 「我保证：不多不少调用一次」
    }
    block()
}

InvocationKind 有四档：EXACTLY_ONCE（正好一次）、AT_LEAST_ONCE、AT_MOST_ONCE（最多一次，比如 ?.let）、UNKNOWN。声明了它，编译器才敢做两件事：① 允许在 lambda 里初始化外部的 val；② 把 lambda 里的数据流分析结果（比如「这里做过判空」）带出到 lambda 外面。

这解释了一个你可能一直觉得理所当然的现象：requireNotNull(x) 之后 x 就变成非空了、check(cond) 之后条件成立了 —— 全都是 contracts 在起作用。标准库里到处都是这种合同，你天天在享受它，只是没见过它的样子。

什么时候值得自己写 contract

说实话：大多数业务代码不需要。它是写工具函数/写库时的东西。三个真实值得写的场景：

• 自定义的校验函数：fun Response?.isValid(): Boolean，让调用方 if (resp.isValid()) 之后能直接用 resp.body。
• 自定义的作用域函数：你写了个 inline fun <T> T.applyIf(cond: Boolean, block: T.() -> Unit): T，加上 callsInPlace(block, AT_MOST_ONCE) 才能和标准库的作用域函数一样好用。
• 自定义的断言：项目里的 fun requireLoggedIn(user: User?)，加 returns() implies (user != null)，调用之后编译器就认它非空了。

fun f(x: Any) {
    if (x !is Int && x !is String) return    // 排除掉其他一切

    val r = when (x) {      // 编译器知道:此处 x 只可能是 Int 或 String
        is Int -> "int"
        is String -> "str"
    }                       // ✓ 不用再写 else 了
}

if (obj instanceof String s && s.length() > 5) {
    System.out.println(s.toUpperCase());   // s 已经是 String
}

下一章进入 Kotlin 泛型 —— 那个让你每隔几个月就要重新查一遍「in 和 out 到底哪个是哪个」的地方。这次我们把它一次性钉死。