Kotlin 之所以常被认为“比 Java 更稳”，空安全是最核心的原因之一。它不是简单提供几个判空语法糖，而是把“这个值能不能为 null”直接放进类型系统里，在编译阶段就拦下大量潜在错误。读完这篇你可以建立一套实用判断：什么时候该声明可空类型，什么时候该尽早消化 null，以及哪些写法虽然能通过编译，但仍然可能把 NPE 留到运行时。
为什么 Kotlin 把空安全放在核心位置
NullPointerException 为什么长期难治
在 Java 这类传统语言里，空指针异常（NPE）一直是最常见的运行时错误之一。问题的根源在于：变量是否可能为 null，往往不会直接体现在类型上，编译阶段也很难完整发现，结果就是代码运行到某个分支时才突然崩溃。
Kotlin 的设计目标是什么
Kotlin 直接把空值问题前移到编译阶段处理，核心原则很明确：
- 默认情况下，类型是非空的
- 必须显式声明可空类型
- 编译器强制检查可空值的使用
编译期检查能解决什么
Kotlin 编译器会分析每个表达式的可空性。如果某段代码可能触发 NPE，编译器通常会直接报错，要求开发者先处理空值再继续使用。这也是 Kotlin 空安全真正有价值的地方：它减少的不是“写判空代码的工作量”，而是线上才暴露问题的概率。
可空类型怎么声明，和普通类型差在哪
语法很简单：类型后面加
// 非空类型
var name: String = "Kotlin"
// 可空类型
var nullableName: String = null
// 各种类型的可空声明
var age: Int = null
var list: List = null
非空类型和可空类型的行为区别
- 非空类型：保证不为
null，可以直接访问成员 - 可空类型：值可能为
null，使用前必须先做空安全处理
类型层次要怎么理解
在 Kotlin 的类型系统里，String 是 String 的子类型。也就是说，非空值可以安全赋给可空类型；但反过来不行，因为编译器不能确认一个可空值在当前时刻一定非空。
这些地方最常见可空声明
// 函数参数
fun process(text: String) { /* ... */ }
// 类属性
class User(val name: String, val middleName: String)
// 集合元素
val list: List = listOf("a", null, "c")
这里顺便要区分两个很容易混淆的概念：List 表示“列表存在，但元素可以为 null”；List 表示“列表本身可能为 null”。这两个类型在业务语义上完全不同。
Kotlin 是怎么检查可空性的
编译器会持续跟踪可空性
Kotlin 编译器会跟踪每个表达式的类型状态，重点保证三件事：
- 非空类型变量不会接收
null值 - 可空类型变量在使用前完成空检查
- 类型转换过程符合可空性约束
可空性也会参与类型推断
// 类型推断
val inferredNonNull = "Hello" // 推断为 String
val inferredNullable = null // 推断为 Nothing
val result = if (condition) "Yes" else null // 推断为 String
这说明 Kotlin 的类型推断并不是“只看值长什么样”，而是会把分支结果、空值可能性一起纳入判断。
和 Java 互操作时要特别注意平台类型
与 Java 互操作时，来自 Java 的类型会变成所谓“平台类型”，写作 String!。它的含义不是一种正式语法，而是 Kotlin 无法确定这个值到底该当成可空还是非空处理，因此风险会转移到开发者身上。
// Java方法：public String getValue();
val kotlinValue: String = javaObject.getValue() // 作为可空处理
val kotlinValue2: String = javaObject.getValue() // 作为非空处理，但可能引发NPE
如果这类返回值来自外部库、老项目或注解不完整的 Java 代码，保守做法通常是先按可空处理，再在 Kotlin 一侧尽早收敛。
函数、属性和局部变量中该怎么用空安全
函数参数：是否允许空值，要在签名里说清楚
// 可空参数
fun printLength(text: String) {
if (text != null) {
println(text.length) // 智能转换：text现在是String
}
}
// 非空参数
fun printLengthNonNull(text: String) {
println(text.length) // 安全：text保证非空
}
如果业务上不接受空值，就直接声明成非空参数；只有当“没有值”本身就是合法输入时，才使用 String 这类类型。
返回值：可空返回适合表达“可能找不到”
// 可空返回值
fun findUser(id: Int): User? {
return if (id > 0) User("John") else null
}
// 非空返回值
fun requireUser(id: Int): User {
return findUser(id) : throw IllegalArgumentException("User not found")
}
findUser() 这种接口适合表达“查找结果可能不存在”；而 requireUser() 则体现另一种思路：在边界处把空值转换成明确异常，后续调用方都可以拿到非空结果。
属性：可空、初始化与 lateinit 的边界要分清
class Person {
// 非空属性必须在构造时初始化
val name: String
// 可空属性可以延迟初始化
var nickname: String = null
// 延迟初始化属性（非空但无需立即初始化）
lateinit var address: String
init {
name = "Default"
}
}
这里最容易混淆的是：nickname: String = null 表示“这个属性允许没有值”；lateinit var address: String 表示“这个属性不允许为 null，但初始化时机延后”。两者表达的不是同一件事。
局部变量：智能转换是否生效，和可变性有关
fun processData() {
// 可空局部变量
var message: String = null
// 可变性影响智能转换
var mutableMessage: String = "Hello"
if (mutableMessage != null) {
// 警告：mutableMessage可能已被修改
println(mutableMessage.length)
}
val immutableMessage: String = "Hello"
if (immutableMessage != null) {
// 安全：智能转换生效
println(immutableMessage.length)
}
}
原因在于 var 可能在检查之后被重新赋值，而 val 更容易让编译器确认状态稳定。因此，想让智能转换更可靠，优先使用不可变局部变量是更稳的选择。
最常用的空安全操作符和处理方式
安全调用、Elvis、非空断言和安全转换
// 安全调用操作符（.）
val length: Int = user.name.length
// Elvis操作符（:）
val displayName = user.name : "Anonymous"
// 非空断言（!!）——谨慎使用
val unsafeLength = user!!.name!!.length // 可能抛出NPE
// 安全转换（as）
val stringValue = obj as String // 失败时返回null
这几个操作符里，. 和 : 是最常见、也最推荐的日常工具；!! 虽然省事，但本质上是把编译期问题重新丢回运行时。
尽早消化 null，减少可空性传播
// 使用默认值而非null
fun greet(name: String): String {
return "Hello, ${name : "Guest"}"
}
// 使用空集合而非null
val emptyList: List = emptyList() // 优于 List = null
很多场景里，真正要避免的不是“出现 null”，而是“null 一路在系统里扩散”。能用默认值、空集合或明确分支提前收口，代码会更容易维护。
常见陷阱与更稳妥的写法
陷阱 1：过度依赖 !!
// 避免
val risky = possiblyNullValue!!
// 推荐
val safe = possiblyNullValue : defaultValue
!! 适合极少数“逻辑上此处必不为空，且失败就该直接暴露”的场景，但不应成为日常空安全方案。
陷阱 2：忽略平台类型的风险
// 来自Java的返回值
val javaValue = javaClass.getNullableValue()
// 不安全
val length = javaValue.length // 可能NPE
// 安全处理
val safeLength = javaValue.length : 0
只要值来自 Java 或外部边界，就要假设它的可空信息可能不完整，尤其是在旧代码和第三方库里更常见。
陷阱 3：误判智能转换的适用范围
var globalValue: String = "test"
fun problematic() {
if (globalValue != null) {
// 危险：另一个线程可能修改globalValue
println(globalValue.length) // 编译器警告
}
}
// 解决方案：使用局部副本
fun safe() {
val localValue = globalValue
if (localValue != null) {
println(localValue.length) // 安全
}
}
面对可变的共享状态时，先复制到局部不可变变量，再继续使用，通常比依赖编译器“猜到你的意图”更稳。
陷阱 4：集合本身可空，和元素可空不是一回事
// List 与 List 的区别
val listOfNullables: List = listOf("a", null, "c")
val nullableList: List = null
// 安全处理集合中的可空元素
val nonNullElements = listOfNullables.filterNotNull()
在接口设计里，把“空列表”和“没有列表”区分清楚，往往能减少很多无意义的判空分支。
一套实用的 Kotlin 空安全写法建议
- 优先使用非空类型，只在业务上确实可能缺值时才声明可空
- 尽早处理空值，不要让可空性在多层调用里持续传播
- 能用默认值就别返回 null，能用空集合就别返回可空集合
- 与 Java 互操作时更保守，平台类型优先当作可空值处理
- 把
!!当成例外手段，而不是常规写法 - 测试边界情况，尤其是外部输入、平台类型和集合中的可空元素
// 使用let处理可空值
user.let {
println("User: ${it.name}")
processUser(it)
}
// 空安全的扩展函数
fun String.orEmpty(): String = this : ""
// 使用require或check进行参数验证
fun process(input: String) {
require(input != null) { "Input cannot be null" }
// input现在智能转换为非空
}
如果把这些规则落实到日常编码里，Kotlin 的空安全优势会非常明显：错误更早暴露，接口语义更清楚，运行时出现 NullPointerException 的概率也会显著下降。
