空安全机制的底层真相

从"十亿美元错误"到类型系统的革命

1965 年，英国计算机科学家 Tony Hoare 在设计 ALGOL W 语言时，做了一个"当时看起来无法抗拒"的决定——引入空引用（Null Reference）。他的初衷很简单：既然引用可以指向一个对象，那让它也能"指向空"是最省事的做法。这个决定后来被他本人称为**"我的十亿美元错误"（My Billion Dollar Mistake）**——因为在此后的半个世纪里，空引用催生了无数的系统崩溃、安全漏洞和难以排查的 Bug，造成的经济损失远超十亿美元。

Java 完整地继承了这个设计：任何引用类型的变量都可以是 null，而编译器对此一无所知。你声明了一个 String name，编译器保证它要么是一个 String 对象，要么是 null——但它不会告诉你到底是哪种情况。于是，每一次访问引用类型的属性或方法，都是一次潜在的"踩雷"：

// Java：编译器不发出任何警告，运行时直接崩溃
String name = getUserName();  // 可能返回 null
int length = name.length();   // 💥 NullPointerException

NullPointerException（NPE）长期稳居 Android 崩溃率排行榜第一位。它的危险不在于它会崩溃——崩溃至少说明问题暴露了——而在于 null 可能在系统中静默传播，直到离真正的错误现场很远的地方才爆炸，让你花数小时追溯根源。

Kotlin 的解决方案从根本上不同于"小心地检查 null"这种防御式编程。它的哲学是：让编译器替你检查。Kotlin 将可空性编码进了类型系统——String 和 String? 是两个不同的类型，编译器在编译期就能检测出所有潜在的空指针问题。

在上一篇文章中，我们已经看到了 Kotlin 类型层级中可空类型的位置（Any? > T? > Nothing?），以及编译器通过 @NotNull 注解和 Intrinsics.checkNotNullParameter() 实现的运行时快速失败机制。本文将进入空安全体系的纵深地带——拆解每一种空安全操作符在字节码层面的编译产物，揭开编译器为你生成的"保护代码"的全貌。

可空类型 T? 的编译原理

类型系统中的 T 与 T?

在 Kotlin 的类型系统中，每一个类型 T 都有一个对应的可空版本 T?。它们之间的关系清晰而严格：

• T 是 T? 的子类型——一个非空值可以赋给可空变量
• T? 不是 T 的子类型——一个可空值不能赋给非空变量

var nonNull: String = "hello"
var nullable: String? = "hello"

nullable = nonNull     // ✅ 子类型赋值：String → String?
nonNull = nullable     // ❌ 编译错误：Type mismatch，String? 不是 String 的子类型

把 String 和 String? 想象成两种不同规格的容器。String 是一个"必须装东西的盒子"——工厂出厂时保证里面有货；String? 是一个"可能空着的盒子"——标签上写着"可能为空"。你可以把一个"必有货"的盒子放在"可能空"的货架上（安全降级），但不能把"可能空"的盒子当作"必有货"来使用（信息丢失）。

字节码层面：T 和 T? 的区别在哪里

一个关键事实是：在 JVM 字节码层面，String 和 String? 没有类型上的区别——它们都是 java.lang.String。JVM 本身不理解 Kotlin 的可空性概念。那么编译器如何保障空安全？答案是两道防线：

第一道防线：编译期类型检查

这是最核心的防线——编译器维护着一份独立于 JVM 类型系统的可空性信息表。它在编译期就阻止了所有不安全的操作：

fun process(name: String?) {
    println(name.length)     // ❌ 编译错误：Only safe (?.) or non-null asserted (!!) calls
                              //    are allowed on a nullable receiver of type String?
    println(name?.length)    // ✅ 使用安全调用
}

第二道防线：@Nullable / @NotNull 注解 + 运行时守卫

编译器在生成的字节码中，为每个参数和返回值标注 @Nullable 或 @NotNull 注解。对于非空参数，还会在函数入口插入 Intrinsics.checkNotNullParameter() 守卫——这是防御来自 Java 代码的非法 null：

fun greet(name: String, title: String?) {
    println("$title $name")
}

编译后的字节码（等效 Java）：

public static final void greet(@NotNull String name, @Nullable String title) {
    // 只有非空参数 name 才有运行时守卫
    Intrinsics.checkNotNullParameter(name, "name");
    // title 是可空的，不需要守卫
    System.out.println(title + " " + name);
}

注意：可空参数 title 没有运行时检查——因为它本来就允许为 null。运行时守卫只保护非空参数免受 Java 代码的侵入。

安全调用链 ?. 的字节码拆解

基本用法与语义

安全调用操作符 ?. 是 Kotlin 空安全体系的核心工具。它的语义很简单：如果接收者不为 null，执行调用并返回结果；如果接收者为 null，跳过调用并返回 null。

val name: String? = getNameOrNull()
val length: Int? = name?.length  // 如果 name 非空，返回 length；否则返回 null

字节码拆解：编译器生成了什么

安全调用没有任何运行时魔法——编译器将 ?. 转换为标准的 JVM 分支指令。让我们反编译来看：

fun safeLength(name: String?): Int? {
    return name?.length
}

编译后的字节码（简化）：

ALOAD 0                  // 加载 name 到操作数栈
DUP                      // 复制 name 引用（一份用于空检查，一份用于后续调用）
IFNULL L1                // 如果 name 为 null，跳转到 L1
INVOKEVIRTUAL String.length ()I   // name 非空，调用 length()
INVOKESTATIC Integer.valueOf (I)Ljava/lang/Integer;  // 装箱：int → Integer
GOTO L2                  // 跳转到返回处 L2

L1:                      // name 为 null 的分支
POP                      // 清除栈上多余的 null 引用
ACONST_NULL              // 将 null 压入栈

L2:                      // 两个分支汇合
ARETURN                  // 返回结果（Integer 对象或 null）

等效的 Java 伪代码：

public static final Integer safeLength(String name) {
    return name != null ? Integer.valueOf(name.length()) : null;
}

关键观察：

1. ?. 就是一个 if-null 分支——IFNULL 指令是 JVM 原生的空值检查指令，没有额外方法调用
2. 返回类型从 int 变为 Integer——因为结果可能是 null，必须使用引用类型
3. 零运行时开销——整个安全调用的成本就是一条 IFNULL 跳转指令，现代 CPU 的分支预测器可以高效处理

链式安全调用：逐级短路

安全调用的真正威力在于链式调用——多个 ?. 串联时，编译器生成逐级短路的分支代码：

data class Address(val city: String?)
data class User(val address: Address?)

fun getCityName(user: User?): String? {
    return user?.address?.city
}

编译后的字节码逻辑（等效 Java）：

public static final String getCityName(User user) {
    String result;
    if (user != null) {
        Address address = user.getAddress();
        if (address != null) {
            result = address.getCity();
        } else {
            result = null;
        }
    } else {
        result = null;
    }
    return result;
}

对应的字节码模式是级联的 IFNULL 跳转：

ALOAD 0              // 加载 user
DUP
IFNULL L_EXIT        // user == null → 直接返回 null

INVOKEVIRTUAL User.getAddress()  // user.address
DUP
IFNULL L_EXIT        // address == null → 返回 null

INVOKEVIRTUAL Address.getCity()  // address.city
GOTO L_END

L_EXIT:
POP
ACONST_NULL

L_END:
ARETURN

把链式安全调用想象成一串安全门禁系统。每一道门（?.）都独立检查你的通行证——如果你在第一道门就被拒绝（null），不会再去检查后面的门，整条通道直接返回"拒绝"（null）。这就是"短路（Short-Circuit）"的含义。

安全调用 + let：惯用模式

安全调用经常与 let 组合，实现"非空时执行某段逻辑"的模式：

val name: String? = getUserName()

// 只在 name 非空时执行 lambda
name?.let { nonNullName ->
    println("Hello, ${nonNullName.uppercase()}")
    sendGreeting(nonNullName)
}

由于 let 是 inline 函数，编译后的字节码不会产生 lambda 对象——整段代码被内联展开为一个简单的 if 分支。

Elvis 操作符 ?: 的本质

不是三目运算符的语法糖

Elvis 操作符 ?: 经常被描述为"类似于三目运算符的空值合并操作"，但这只说对了一半。它的完整语义是：如果左侧表达式的值不为 null，返回左侧的值；否则，求值并返回右侧的表达式。

val name: String = input ?: "Unknown"  // input 非空 → 用 input；input 为 null → 用 "Unknown"

关键在于：右侧不仅可以是一个值，还可以是任何表达式——包括 throw、return、甚至函数调用：

// 右侧是 throw——利用 Nothing 的子类型特性
val config = loadConfig() ?: throw IllegalStateException("Config not found")

// 右侧是 return——提前退出函数
fun process(data: String?) {
    val value = data ?: return  // data 为 null 则直接返回，后续代码中 value 是 String
    println(value.uppercase())  // 编译器知道 value 是非空的 String
}

// 右侧是函数调用
val port = configPort ?: getDefaultPort()

字节码拆解

fun getNameOrDefault(name: String?): String {
    return name ?: "Unknown"
}

编译后的字节码（简化）：

ALOAD 0                  // 加载 name
DUP                      // 复制引用
IFNULL L1                // 如果 name 为 null，跳到 L1
GOTO L2                  // name 非空，跳到 L2（直接使用 name）

L1:
POP                      // 丢弃栈上的 null
LDC "Unknown"            // 加载默认值 "Unknown"

L2:
ARETURN                  // 返回结果

等效 Java：

public static final String getNameOrDefault(String name) {
    return name != null ? name : "Unknown";
}

Elvis + throw / return 的特殊编译

当 Elvis 的右侧是 throw 或 return 时，编译器利用 Nothing 的特性做了更精确的类型推断：

fun requireName(name: String?): String {
    return name ?: throw IllegalArgumentException("Name is required")
}

编译后的字节码（等效 Java）：

public static final String requireName(String name) {
    if (name != null) {
        return name;
    } else {
        throw new IllegalArgumentException("Name is required");
        // 这里没有 return——因为 throw 之后代码不可达
    }
}

编译器知道：throw 表达式的类型是 Nothing，Nothing 是 String 的子类型，所以 name ?: throw ... 的整体类型可以被推断为 String（非空），而不是 String?。

嵌套 Elvis：从左到右求值

Elvis 操作符可以嵌套使用，求值顺序为从左到右：

val result = first ?: second ?: third ?: "default"
// 等价于：
// val result = first ?: (second ?: (third ?: "default"))
// 但实际求值是从左到右的短路逻辑：
// 1. first 非空 → 返回 first
// 2. first 空 → 检查 second
// 3. second 非空 → 返回 second
// 4. second 空 → 检查 third
// 5. third 非空 → 返回 third
// 6. third 空 → 返回 "default"

非空断言 !! 的危险性

!! 做了什么

非空断言操作符 !! 是 Kotlin 空安全体系中唯一可以主动引发 NPE 的操作。它的语义是：将一个可空类型 T? 强制转换为非空类型 T，如果值为 null，立即抛出 KotlinNullPointerException。

val name: String? = getNameOrNull()
val length = name!!.length  // 如果 name 是 null → 💥 KotlinNullPointerException

字节码分析：!! 编译成了什么

fun forceLength(name: String?): Int {
    return name!!.length
}

编译后的字节码（等效 Java）：

public static final int forceLength(String name) {
    Intrinsics.checkNotNull(name);   // 如果 name 为 null，抛出 NullPointerException
    return name.length();            // 到这里 name 保证非空
}

对应的字节码指令：

ALOAD 0                  // 加载 name
DUP                      // 复制引用（一份用于检查，一份后续使用）
INVOKESTATIC kotlin/jvm/internal/Intrinsics.checkNotNull (Ljava/lang/Object;)V
// checkNotNull 内部实现：
//   if (obj == null) throw new NullPointerException("null cannot be cast to non-null type")
INVOKEVIRTUAL java/lang/String.length ()I
IRETURN

为什么 !! 应该被视为代码异味（Code Smell）

!! 本质上是在对编译器说："闭嘴，我知道我在做什么。"但问题在于——你真的知道吗？

!! 的危险之处在于：

1. 它消解了编译期保障。Kotlin 空安全体系的核心价值是"在编译期就发现问题"。使用 !! 等于主动放弃了这层保护，把错误推迟到运行时
2. 它隐藏了设计问题。当你发现自己需要使用 !! 时，往往意味着 API 设计存在缺陷——为什么一个明显不应该为空的值，类型是 T?？
3. 它让 NPE 的根源模糊化。原本 Java 中的 NPE 至少告诉你是在哪一行的哪个调用出了问题，而在一行连续使用多个 !!，崩溃时无法确定是哪个值为空

// ❌ 反模式：一行多个 !!，崩溃时无法定位
val cityName = user!!.address!!.city!!.uppercase()
// 如果崩溃了，是 user 为空？address 为空？还是 city 为空？

// ✅ 正确做法：使用安全调用链 + Elvis
val cityName = user?.address?.city?.uppercase() ?: "Unknown"

何时可以使用 !!

极少数情况下 !! 是合理的：

// 场景一：在已有 null 检查的作用域内，编译器因为技术限制无法智能转换
// 例如 var 变量被 lambda 捕获后无法智能转换
private var cachedData: Data? = null

fun processData() {
    if (cachedData != null) {
        // 编译器无法智能转换 var 属性（可能被其他线程修改）
        // 此时 !! 是合理的，但更好的做法是先赋值给 val 局部变量
        val data = cachedData!!  // 可接受，但更好的方式见下面
    }

    // ✅ 更推荐的写法：
    val data = cachedData ?: return
    process(data)  // data 已被推断为非空
}

// 场景二：测试代码中，明确希望空值导致测试失败
@Test
fun `test user creation`() {
    val user = createUser("test")
    // 在测试中，!! 让测试快速失败，错误信息明确
    assertEquals("test", user!!.name)
}

安全类型转换 as? 的底层实现

as vs as?：崩溃与优雅

Kotlin 提供两种类型转换操作：

• as（不安全转换）：如果转换失败，抛出 ClassCastException
• as?（安全转换）：如果转换失败，返回 null

val obj: Any = "Hello"

val str1: String = obj as String      // ✅ 转换成功
val str2: String? = obj as? String    // ✅ 转换成功，str2 = "Hello"

val num1: Int = obj as Int            // 💥 ClassCastException
val num2: Int? = obj as? Int          // ✅ 转换失败，num2 = null（没有崩溃）

as? 的字节码实现

fun safeCast(obj: Any): String? {
    return obj as? String
}

编译后的字节码：

ALOAD 0                  // 加载 obj
DUP                      // 复制引用
INSTANCEOF java/lang/String   // 类型检查：obj 是 String 吗？
IFEQ L1                  // 如果不是（检查失败），跳到 L1
CHECKCAST java/lang/String    // 执行实际的类型转换
GOTO L2                  // 转换成功，跳到返回处

L1:                      // 类型不匹配的分支
POP                      // 丢弃栈上的 obj
ACONST_NULL              // 压入 null

L2:
ARETURN                  // 返回结果（String 或 null）

等效 Java：

public static final String safeCast(Object obj) {
    return obj instanceof String ? (String) obj : null;
}

关键设计：as? 先用 instanceof 检查，只有检查通过才执行 checkcast——这保证了 checkcast 永远不会抛出 ClassCastException。安全性来自两条指令的先后顺序，而不是额外的异常捕获。

as? vs is + 智能转换的选择

as? 和 is 检查在功能上有重叠，但适用场景不同：

// 场景一：需要转换后的值，但不确定类型是否匹配
// 适合 as?
val length = (obj as? String)?.length ?: -1

// 场景二：根据类型执行不同逻辑
// 适合 is + 智能转换
when (obj) {
    is String -> println(obj.length)       // 智能转换
    is Int -> println(obj + 1)             // 智能转换
    else -> println("Unknown type")
}

平台类型（Platform Types）：Java 互操作的灰色地带

问题的根源：Java 的可空性信息缺失

当 Kotlin 调用 Java 代码时，面临一个根本问题：Java 的类型系统不区分可空和非空。一个 Java 方法返回 String，Kotlin 不知道这个 String 是"保证非空"还是"可能为空"。

// Java 代码
public class JavaUser {
    public String getName() {
        return name;  // 可能返回 null，也可能不会——Java 编译器不关心
    }
}

如果 Kotlin 把所有 Java 返回值都视为 T?（可空），安全但极度繁琐——即使你知道某个 Java 方法永远不会返回 null，也必须到处写 ?. 或 !!：

// 如果 Java 返回值全部视为可空——安全但不可持续
val name: String? = javaUser.getName()
val length = name?.length ?: 0  // 每次都要处理空值，即使你知道它不可能为空

如果 Kotlin 把所有 Java 返回值都视为 T（非空），简洁但危险——如果 Java 方法返回了 null，就会在赋值时崩溃。

Kotlin 的折中方案：平台类型 T!

Kotlin 引入了平台类型（Platform Type）作为折中。平台类型在编译器内部用 T! 表示（如 String!），但你不能在自己的 Kotlin 代码中书写 T!——它是一个"不可标记的（non-denotable）"类型。

平台类型的语义是：编译器放松了空安全检查——你可以把它当作 T 使用，也可以当作 T? 使用，选择权交给你。

// Java 方法返回 String!（平台类型）
val name1: String = javaUser.getName()   // 当作非空——如果实际是 null，运行时崩溃
val name2: String? = javaUser.getName()  // 当作可空——始终安全
val name3 = javaUser.getName()           // 类型推断为 String!——编译器不强制你选

平台类型的运行时保护

当你把平台类型赋值给非空类型变量时，编译器会自动插入运行时检查：

val name: String = javaUser.getName()  // 显式声明为非空

编译后的字节码（等效 Java）：

String name = javaUser.getName();
Intrinsics.checkNotNullExpressionValue(name, "getName(...)");
// 如果 getName() 返回 null：
// → 抛出 NullPointerException: "getName(...) must not be null"

编译器插入的 checkNotNullExpressionValue 实现本质上是：

public static void checkNotNullExpressionValue(Object value, String message) {
    if (value == null) {
        // sanitizeStackTrace 会清理掉 Intrinsics 的内部堆栈帧，让报错更清晰
        throw sanitizeStackTrace(new NullPointerException(message + " must not be null"));
    }
}

这就是快速失败（Fail-Fast）原则的体现——宁可在赋值点立即崩溃并给出清晰的错误信息，也不让 null 潜入 Kotlin 的类型安全区域后造成远处的难以排查的崩溃。

Java 空值注解：消除平台类型

如果 Java 代码使用了空值注解，Kotlin 编译器能读取这些元数据，将平台类型解析为确切的可空/非空类型：

// Java 代码使用了 @NonNull 和 @Nullable 注解
public class JavaUser {
    @NonNull
    public String getName() { return name; }  // Kotlin 看到的类型是 String（非空）

    @Nullable
    public String getEmail() { return email; } // Kotlin 看到的类型是 String?（可空）
}

Kotlin 识别多种来源的空值注解：

工程实践建议：如果你维护的 Java 库会被 Kotlin 调用，添加空值注解是提升互操作体验最有效的手段。推荐使用 @NonNull / @Nullable（来自 androidx.annotation 或 org.jetbrains.annotations），让 Kotlin 调用方获得完整的编译期空安全保障。

平台类型传播的危险

平台类型最大的风险在于传播——如果你不显式声明类型，平台类型会"泄漏"到你的 Kotlin API 中：

// ❌ 危险：返回类型被推断为平台类型 String!
fun getUserName() = javaUser.getName()
// 调用方不知道返回值是否可空——隐患传播

// ✅ 安全：显式声明返回类型
fun getUserName(): String? = javaUser.getName()
// 调用方明确知道需要处理空值

核心原则：在 Java/Kotlin 交互的边界处，始终显式声明 Kotlin 侧的类型。不要让平台类型泄漏到你的公开 API 中。

空安全与集合：四种类型的精确区分

两个独立维度的组合

Kotlin 的集合类型在空安全方面有两个独立的维度：集合本身是否可空，以及集合元素是否可空。组合起来就是四种类型：

val a: List<String>   = listOf("a", "b")     // 集合非空，元素非空
val b: List<String?>  = listOf("a", null)     // 集合非空，元素可空
val c: List<String>?  = null                  // 集合可空，元素非空
val d: List<String?>? = null                  // 集合可空，元素可空

每种类型在使用时面临的约束完全不同：

// List<String>：最安全，直接使用
a.forEach { println(it.length) }       // ✅ 无需任何空检查

// List<String?>：集合可直接使用，但元素需要空检查
b.forEach { println(it?.length ?: 0) } // ✅ 元素可能为 null

// List<String>?：集合需要空检查，但元素安全
c?.forEach { println(it.length) }      // ✅ 集合可能为 null

// List<String?>?：双重空检查
d?.forEach { println(it?.length ?: 0) } // ✅ 集合和元素都可能 null

字节码层面：JVM 类型擦除的影响

在 JVM 字节码层面，这四种类型编译后是完全相同的 java.util.List——因为 JVM 泛型通过类型擦除实现。空安全的区别完全在编译期体现：

// 以下四种 Kotlin 声明的 JVM 字节码签名
List<String>    →  Ljava/util/List;  // @NotNull List, @NotNull 元素
List<String?>   →  Ljava/util/List;  // @NotNull List, @Nullable 元素
List<String>?   →  Ljava/util/List;  // @Nullable List, @NotNull 元素
List<String?>?  →  Ljava/util/List;  // @Nullable List, @Nullable 元素
// 区别仅在注解中体现

可空元素的过滤：filterNotNull()

Kotlin 标准库提供了 filterNotNull() 函数，专门用于将 List<T?> 转换为 List<T>：

val mixedList: List<String?> = listOf("hello", null, "world", null)
val cleanList: List<String> = mixedList.filterNotNull()
// cleanList = ["hello", "world"]，类型是 List<String>（元素保证非空）

filterNotNull() 的实现简洁而巧妙：

// kotlin-stdlib 源码
public fun <T : Any> Iterable<T?>.filterNotNull(): List<T> {
    return filterNotNullTo(ArrayList<T>())
}

public fun <C : MutableCollection<in T>, T : Any> Iterable<T?>.filterNotNullTo(
    destination: C
): C {
    for (element in this) {
        if (element != null) {
            destination.add(element)
        }
    }
    return destination
}

注意泛型约束 T : Any——这确保了输出列表的元素类型是非空的。这是 Kotlin 类型系统中泛型约束和空安全协同工作的一个经典案例：通过约束 T 必须是 Any 的子类型（即非空），编译器在类型层面就保证了返回的列表不会包含 null。

契约（Contracts）与空安全：教编译器"更多事实"

编译器的局限性：黑盒函数

Kotlin 的智能转换（smart cast）依赖于编译器的控制流分析。当编译器能直接"看到"空检查的逻辑时，它可以做出精确的推断：

fun process(name: String?) {
    if (name != null) {
        // ✅ 编译器看到了 null 检查，自动智能转换为 String
        println(name.length)
    }
}

但如果空检查的逻辑被提取到一个独立的函数中，编译器就"看不到"了——因为它不会分析函数的内部实现：

fun isNotNullOrEmpty(str: String?): Boolean {
    return str != null && str.isNotEmpty()
}

fun process(name: String?) {
    if (isNotNullOrEmpty(name)) {
        println(name.length)  // ❌ 编译错误！编译器不知道 isNotNullOrEmpty
                               //    返回 true 意味着 name 非空
    }
}

对编译器来说，isNotNullOrEmpty 是一个黑盒——它只知道这个函数返回 Boolean，但不知道返回值和参数的可空性之间有什么关系。

契约（Contracts）：打破黑盒

Kotlin 的**契约（Contracts）**机制允许函数向编译器声明额外的语义保证——"如果我返回了 X，那么 Y 一定成立"。

import kotlin.contracts.*

@OptIn(ExperimentalContracts::class)
fun isNotNullOrEmpty(str: String?): Boolean {
    // 契约声明：如果本函数返回 true，那么 str 保证不是 null
    contract {
        returns(true) implies (str != null)
    }
    return str != null && str.isNotEmpty()
}

fun process(name: String?) {
    if (isNotNullOrEmpty(name)) {
        // ✅ 编译通过！契约告诉编译器：isNotNullOrEmpty 返回 true → name 非空
        println(name.length)  // 智能转换为 String
    }
}

契约的两大效果

效果一：returns + implies——条件性类型收窄

returns(value) implies (condition) 表示："如果函数返回 value，那么 condition 在调用点成立。"

@OptIn(ExperimentalContracts::class)
fun requireNotNull(value: Any?): Boolean {
    contract {
        returns(true) implies (value != null)
    }
    return value != null
}

// 标准库中的 requireNotNull 和 checkNotNull 就使用了类似的契约

@OptIn(ExperimentalContracts::class)
fun <T> assertIsType(value: Any?): Boolean {
    contract {
        returns(true) implies (value is T)
    }
    return value is T
}

returns() 不带参数表示"函数正常返回（不抛异常）"：

@OptIn(ExperimentalContracts::class)
fun assertNotNull(value: Any?, message: String) {
    contract {
        returns() implies (value != null)
    }
    if (value == null) throw IllegalArgumentException(message)
}

fun process(data: Data?) {
    assertNotNull(data, "Data must not be null")
    // ✅ 编译通过：如果走到这里，说明 assertNotNull 正常返回了
    //    契约保证此时 data != null
    println(data.name)  // 智能转换为 Data
}

效果二：callsInPlace——Lambda 执行保证

callsInPlace(lambda, kind) 告诉编译器：这个 lambda 参数会在特定条件下被调用。

@OptIn(ExperimentalContracts::class)
inline fun <R> executeOnce(block: () -> R): R {
    contract {
        callsInPlace(block, InvocationKind.EXACTLY_ONCE)
    }
    return block()
}

InvocationKind 有四个级别：

这解释了为什么 run、let、with、apply、also 等标准库函数可以在 lambda 中初始化 val——它们都声明了 callsInPlace(block, EXACTLY_ONCE) 契约：

// kotlin-stdlib 中 run 的声明（简化）
@OptIn(ExperimentalContracts::class)
public inline fun <R> run(block: () -> R): R {
    contract {
        callsInPlace(block, InvocationKind.EXACTLY_ONCE)
    }
    return block()
}

// 因为 run 契约了 EXACTLY_ONCE，所以以下代码合法：
val result: String
run {
    result = computeValue()  // ✅ 编译器知道这个 lambda 恰好执行一次
}
println(result)  // ✅ result 保证已被初始化

契约的本质：编译期元数据，非运行时检查

契约是纯粹的编译期机制——它不会生成任何运行时代码。这意味着：

1. 契约没有运行时开销
2. 如果契约声明与函数实际行为不一致，编译器不会发现——你会得到错误的智能转换结果，导致运行时崩溃

// ⚠️ 危险：契约"撒谎"——声称返回 true 意味着 value 非空，但实际不检查
@OptIn(ExperimentalContracts::class)
fun alwaysTrue(value: Any?): Boolean {
    contract {
        returns(true) implies (value != null)
    }
    return true  // 永远返回 true，即使 value 是 null
}

fun crash() {
    val x: String? = null
    if (alwaysTrue(x)) {
        println(x.length)  // 编译通过！但运行时 💥 NullPointerException
    }
}

契约像是你给编译器签发的一张"保证书"——你保证函数会遵守特定的行为模式。编译器基于信任使用这张保证书来做更精确的推断。但如果保证书是伪造的，所有基于它的推断都会坍塌。

契约的使用限制

当前（Kotlin 2.x），契约有以下限制：

• 只能用于顶层函数（top-level function）或类的成员函数
• 函数必须是 inline 的（对于 callsInPlace 效果）
• 契约声明必须是函数体的第一条语句
• @ExperimentalContracts 注解是必须的——API 仍处于实验阶段
• 编译器不验证契约的正确性——开发者必须自行保证

空安全操作符编译产物速查表

最后，用一张总结表格将所有空安全操作符的行为和编译产物汇总：

小结

本文从字节码层面拆解了 Kotlin 空安全机制的完整面貌：

Kotlin 的空安全不是一个单独的"特性"，而是类型系统的有机组成部分。从类型层级（Any / Any? / Nothing / Nothing?）到操作符（?. / ?: / !! / as?），再到编译器的高级分析能力（智能转换 + 契约），它们共同构成了一套完整的、在编译期就消除绝大部分空指针问题的工程体系。这套体系的底层实现完全依赖标准的 JVM 指令——没有运行时魔法，只有编译器帮你写好的那些你本该手动写的 if (x != null) 检查。