空安全这题"入门"不难，难的是它后面那一串追问：?. 链式调用的返回值类型是什么、?: 的右值什么时候求值、?.let 里的 it 是什么类型、!! 什么时候能用、Compose 里状态的可空性怎么处理。答得好的人有个共同点——不背语法表，而是把"可空性"当成类型层面的契约来讲。
先把结论放在前面：Kotlin 的空安全是编译期能力。 T 与 T? 是两个不同类型，不能互相赋值；?.（安全调用）在接收者为 null 时短路返回 null、且不求值后续链；?:（Elvis）在左值为 null 时返回右值；!! 是断言非空，失败即抛 KotlinNullPointerException；let 是作用域函数，在非空情形下把值作为 it 传入。 核心纪律是：把 null 当成一个需要显式处理的分支，而不是一个可以随手忽略的状态。
机制拆解
?. 的短路语义是这题最值得讲清的一点：a?.b?.c 一旦遇到 null 就立即返回 null，整条链后续的表达式都不再求值。这个"短路"不只是避免崩溃，还有实际意义——比如 user?.address?.city?.length ?: 0，当 user 为 null 时不会去访问任何属性，也不会执行后面的方法调用。 相比 if (user != null && user.address != null ...) 这种写法，?. 链在保证等价语义的同时更短，且编译器能理解。
?: 的求值时机是另一个容易被忽略的点。Kotlin 里 a ?: b 是表达式，b 只在 a 为 null 时才求值。这一点在 a ?: throw IllegalStateException() 与 a ?: expensiveCall() 上差别很大——前者是标准的"必须有值"断言写法，后者是懒执行的兜底。 面试里如果能补一句"右值是懒求值的，所以可以放昂贵操作或抛异常"，说明理解到了实现层面。
let 的本质是作用域函数：x?.let { ... } 里的 it 类型是非空的 T（因为已经在非空分支里），这正是它比 if (x != null) { } 更简洁的地方——if 分支里 Kotlin 的智能转换（smart cast）帮不上所有场景（比如 x 是自定义 getter 的属性时智能转换会失效），而 let 通过把值作为参数传入，从类型上彻底绕开了这个问题。
!! 的定位要说清楚：它是断言，语义是"此处已确认非空，只是编译器看不到"。合规的使用场景有三类：①框架保证非空且已验证；②lateinit 属性且已完成赋值；③测试代码里为了简洁。其余场景都该用 ?. 或显式处理。
这些坑的正确绕法
最常见的坑是全代码 !! 泛滥，空安全形同虚设，NPE 只是换了个异常类名。 表现是项目里 !! 命中几百处，lint 警告被批量压制，出问题时堆栈是 KotlinNullPointerException 但看不出是哪一处 !! 造成的——比 Java 的 NullPointerException 更难定位，因为语义暗示"这里不该为 null"。 根因是把"消除编译警告"当目标。修法是分三步：开 lint 把 UnsafeCallOnNullableType 提到 error 级别；逐处替换为 ?.、Elvis 或显式判空；只在框架保证处保留并配注释说明为什么可以断言。
其次是 ?.let 用得过多，把一段普通逻辑切成多层嵌套。 表现是三四个 ?.let 串起来，IDE 缩进越来越深，可读性反而下降。根因是把 let 当成了"消除 if 的工具"，而不是"在非空作用域内安全访问的工具"。判据是：如果嵌套超过两层，就该考虑用局部变量、if 的 early return、或者把数据流改成不可变对象从头构建，避免在已有对象上一层层修补。
还有一个更隐蔽的坑：把 null 当成"业务上的合法空态"，用可空类型一路传下去。 表现是数据模型里几十个字段都是 T?，到 UI 层才做一次兜底，结果中间任何一处漏判就崩。Kotlin 社区的做法是"null 滥用是设计问题"——业务上本来就存在的空（比如接口返回的字段可能缺失）应该在边界处一次性转换成不可变的数据类，而不是让可空性渗透进整个业务。 举例：接口返回 Map<String, Any?>，进入业务时立刻 toUiState() 转成 UiState(items: List<Item>, error: String?)，让可空性收敛在少数几个字段上。
代码里见真章
看一段能直接跑的代码，把上面的机制落到具体写法上：
// 1) ?. 短路：整条链遇 null 即返回，不求值后续
val city: String? = user?.address?.city // 类型仍是 String?
val len: Int = user?.address?.city?.length ?: 0 // 兜底给 0
// 注意：? 的右值是懒求值的
val cfg = loadOrNull() ?: throw IllegalStateException("配置未加载")
// 2) let：把非空值带进作用域，it 类型是非空的 T
val name = user?.let {
"${it.name}, ${it.age}" } // it: User（非空）
// 需要多个值时用具名参数，比 it 更清楚
user?.let {
u -> viewModel.submit(u.id, u.name) }
// 3) ?: 的三种典型形态
val a = maybe ?: 0 // 给默认值
val b = maybe ?: throw IllegalArgumentException("缺失") // 断言
val c = maybe ?: run {
expensiveFallback() } // 懒求值兜底
// 4) !! 只在"框架保证"处用，并写清理由
val v = view!!.tag as String // 反例风格；下面才是可接受的
// 正例：已判空 + 泛型方法内断言
fun <T> View.requireTag(): T {
val t = tag ?: error("View 未设置 tag: $this")
@Suppress("UNCHECKED_CAST")
return t as T
}
// 5) 边界收敛：把可空性挡在数据入口
data class RawUser(val name: String?, val age: String?)
data class UiUser(val name: String, val age: Int) // 领域内不可空
fun RawUser.toUi(): UiUser = UiUser(
name = name ?: "匿名", // 一次兜底，此后一路干净
age = age?.toIntOrNull() ?: 0
)
// 6) 集合与空安全
val first = listOfNotNull(maybeA, maybeB, null) // 过滤 null，得到 List<T>
val idx = map["k"] // Map 取值类型是 T?
这段代码值得盯三处：第一处，?. 与 ?: 组合把整条访问链的兜底收敛到一个地方；第二处，?: 右值懒求值让 throw 与昂贵兜底都变得安全；第三处，toUi() 这个边界函数是全篇最值得搬到项目里的实践——可空性在入口收敛一次，领域内部全是非空类型。
这题在面试里怎么问、怎么答
"?. 和 ?: 有什么区别？"答：?. 处理"对象为 null"，?: 处理"值为 null"；?. 返回可空结果继续传播，?: 把可空转成非空并提供兜底；两者可以连用（a?.b ?: default）。补上求值语义：?. 短路不求值后续，?: 右值懒求值。
"智能转换（smart cast）在什么情况下失效？"给几条：①x 是自定义 getter 的 val，编译器无法保证每次取值都相同；②x 声明为平台类型且来自 Java；③x 存在并发修改的可能（var 且被别的线程改）。这时即使 if (x != null) 之后编译器也不会把它当非空，需要用局部变量（val t = x ?: return）或 let。
"Compose 里的空安全有什么不同？"答：Compose 重组依赖状态读取，状态要放在 remember/mutableStateOf 里；可空状态在重组时若为 null 会导致界面不显示或闪烁，常见做法是定义 UiState 密封类（Loading/Content/Error）来表达互斥状态，避免多个可空字段带来的"半渲染"状态。
"使用中遇到过什么问题？"案例一：把 user?.name ?: "未命名" 直接当昵称展示，结果接口字段名变更时一律变成"未命名"，排查不到是数据问题还是兜底；修复为在边界做映射并对未知字段记日志。案例二：!! 在一个异步回调里，而回调可能在对象初始化前触发，抛 KotlinNullPointerException；定位到 !! 断言的对象尚未赋值；修复为改为状态检查。
再补一个工程上值得讲清的一点：Kotlin 的空安全只管引用，Java 侧与第三方接口仍会漏。 三个常漏的地方：①Java 方法返回平台类型（String!），编译通过但可能为 null；②Java 的 Map.get 返回 V!；③反射与 Gson 反序列化写进去的字段，在 Kotlin 侧被当作非空类型但实际是 null（@JvmField 字段尤其容易）。 对策是在 Java 边界处加一层显式映射，把平台类型转成明确的非空或可空；反序列化模型用可空字段 + 映射函数，让运行时数据的不确定性停留在数据层。这条经验比"少用 !!"更能体现实际项目经验。
给正在准备面试的你
把空安全画成一张"三条路径"的决策图：从一个可空值 x?: T 出发，向上分三支——①要有值：?: 给默认 / ?: throw 断言 / ?: run { 兜底计算 }；②有就用：?. 继续访问 / ?.let { } 进入非空作用域 / ?.also / ?.run；③断言非空：!!（只在框架保证处）。 在"有就用"这一支旁边标一句"it 是非空的 T，这是 let 的核心价值"；在图下方写一条收敛原则：可空性在数据入口转成非空，领域内不再传可空。面试中空安全的问题都能从这张图上找到对应位置。
再补工程案例与踩坑——应用落点是为所有 Java 边界（第三方 SDK、Java API、JSON 映射）加一层显式映射函数，把平台类型转成明确类型；把 !! 收敛到少数工具函数里并开 lint 拦截新增；给每个数据入口补"字段缺失"的兜底与日志，避免静默默认值掩盖问题。
复习时别孤立刷题：类型推断与基本类型——T 与 T? 是两个类型，这是空安全所有语法的根基。
划两句重点：?. 短路不求值后续，?: 右值懒求值；let 里的 it 是非空类型；!! 是断言不是转换，只在框架保证处用；可空性要在数据入口收敛，领域内部用不可变数据类。
下一篇聊 Elvis 运算符与 let：空值处理的组合拳——沿着今天这条主线继续往前走。
如果这篇文章对你有帮助，欢迎点赞、在看、转发三连。你的支持就是这个系列持续更新的动力。
「Android软件开发面试·从入门到精通」连载系列
上一篇：类型推断与基本类型：Kotlin-没有隐式拓宽
下一篇预告：Elvis-运算符与-let：空值处理的组合拳
有任何问题欢迎在评论区留言交流。
