7.1 平台类型与空安全边界

本节摘要：Kotlin 调用 Java 时，Java 返回值的可空性无从得知，编译器把它标记为平台类型——允许当非空用、也允许当可空用，风险自担。这是空安全防线的制度性缺口，也是现代 Kotlin 工程 NPE 的最后堡垒。本节讲平台类型的推断规则、击穿案例、可空性注解的补洞、边界收容的架构纪律，以及相关的一批互操作映射差异。

缺口是怎么来的

第 2 章建立的体系依赖一个前提：每个类型的可空性都写在类型里。Java 没有这个概念——String 与 String? 在 Java 里都是 String，可不可能为 null 只存在于 Javadoc 与口传。当 Kotlin 调用 Java：


// Java 侧
public class SessionHelper {
    public String getToken() { ... }        // 可能返回 null 文档里写了 编译器不知道
}


// Kotlin 侧
val token = sessionHelper.token     // token 的类型显示为 String!
val len = token.length              // 编译通过 直接崩

IDE 里悬停 token，类型显示为 String!——叹号结尾的就是平台类型（platform type）。它的语义是"可空性未知"：Kotlin 允许你把它当非空（直接调 length），也允许当可空（用 ?.），编译器都不拦。当非空用而 Java 实际返回了 null，抛出的就是经典 NPE——第 1 章说的"防线缺口"，具体形态就在这里。

注意推断的细节：平台类型不只出现在直接调用上，还会沿表达式传播。helper.token.length 里，.length 是对平台类型的成员访问，整条表达式仍是平台类型；把平台类型赋给 String 变量，编译器只在公开边界（如函数返回值给外部）插运行时断言，局部使用则完全放行。换句话说，平台类型像未检疫的进口货，在 Kotlin 城市里可以层层转运，直到某个人用了它才出事。

一个真实的击穿案例

某应用的推送处理代码，Java 遗留 SDK：


fun handlePush(intent: Intent) {
    val payload = intent.getStringExtra("payload")   // String! 平台类型
    val title = JSONObject(payload).optString("title")   // payload 为 null 时炸
    showBanner(title, JSONObject(payload))
}

测试环境推送永远带 payload，无事发生；线上有一类静默推送不带 payload——JSONObject(null) 抛 NPE，崩溃平台上的堆栈指向这行 Kotlin 代码，而围观同事的第一反应是"Kotlin 不是空安全吗"。这就是平台类型的欺骗性：代码长得像受保护的 Kotlin，实际裸奔在 Java 边界上。

补洞一：可空性注解

让 Java 侧"自报可空性"是最根本的补法。Java 代码加上注解后，Kotlin 会读取并当真：


import androidx.annotation.Nullable;
import androidx.annotation.NonNull;

public class SessionHelper {
    @Nullable
    public String getToken() { ... }          // Kotlin 视为 String?

    @NonNull
    public User getUser(long id) { ... }      // Kotlin 视为 User 违约抛断言
}

注解家族互相兼容：androidx.annotation、org.jetbrains.annotations、JSR-305 的 javax.annotation、以及 Eclipse 与 FindBugs 系注解，Kotlin 编译器都认。自家 Java 代码逐步补注解，是混合工程里性价比最高的空安全投资——注解一次，全部 Kotlin 调用点永久受益。第三方库没注解的部分，等待上游更新或考虑隔离封装。

@NonNull 的价值常被低估：它不只给 Kotlin 看，Kotlin 编译器还会在调用处生成断言——Java 违约传 null 时立刻抛出带清晰信息的异常，而不是让 null 潜伏到三层调用之外。快速失败在边界上同样是防线。

补洞二：声明收窄与防御家族

拿不到注解时（第三方 SDK、老代码没来得及补），Kotlin 侧在接收点显式声明类型，把平台类型立即转换成确定的可空或非空：


val payload: String? = intent.getStringExtra("payload")   // 显式声明可空
val json = payload?.let { JSONObject(it) } ?: return      // 走第 2 章的消解管线

一行显式声明，平台类型当场终结，后续代码回到受保护世界。标准库还有一批专为平台类型设计的防御函数：


val name: String = intent.getStringExtra("name").orEmpty()   // null 变空串
val tags: List<String> = javaMap[key].orEmpty()               // null 变空列表

orEmpty 家族覆盖 String、List、Set、Map、数组，语义是"null 视为空集合或空串"——适合"缺了就当没有"的展示型数据。配合第 2 章的决策图，边界值的三种归宿各就各位：给默认用 orEmpty 或 Elvis、异常路径提前返回、真可空保持问号。

平台类型的流向与收容

边界收容：架构级的补洞

单点补洞靠注解与声明，架构级补洞靠收容。第 1 章骨架的按层分包在这里兑现设计意图：平台类型只允许出现在 data 层（与 Java SDK、老库打交道的门面），任何值在进入 domain 层之前必须完成可空性判决：


// data 层 门面函数 只此一处接触平台类型
class PushRepo(private val helper: SessionHelper) {
    fun payloadOf(intent: Intent): PushPayload? {          // 判决完成 出关类型确定
        val raw: String? = intent.getStringExtra("payload") // 显式可空
        return raw?.let { PushPayload.parse(it) }
    }
}

// domain 与 ui 层 拿到的永远是确定的 Kotlin 类型
fun handlePush(intent: Intent) {
    val payload = repo.payloadOf(intent) ?: return   // 问号消解 编译器全程盯着
    showBanner(payload.title, payload.body)
}

收容的工程价值在审查聚焦：code review 时只需要盯住 data 层的可空判决是否正确，而不用在全工程搜索平台类型。配合 Detekt 的 UnsafeCallOnNullableType 与平台类型相关检查（第 8 章配置），边界纪律可以机器化。

顺手清点其他映射差异

空安全之外，Kotlin 与 Java 的类型映射还有几处会在迁移期出没。集合读写视角：Java 的 java.util.List 传给 Kotlin 是平台类型的 List（MutableList 与 List 的判断未知），跨边界传集合时选择显式复制与显式声明，别赌运行时形态。关键字冲突：Java 里 is、in、object、fun 是合法标识符，Kotlin 里是关键字——Kotlin 调用时用反引号转义（helper.`is`Valid()），新写的 Kotlin API 直接换个名字。检查异常：Kotlin 调 Java 的受检异常方法不需要 catch，异常直接穿透——第 2 章的收容策略照常适用。静态成员：Java 的静态字段与方法在 Kotlin 里以伴生对象风格的点语法访问（System.currentTimeMillis() 无差别），但 Kotlin 的伴生对象在 Java 眼里是 Outer.Companion 的实例成员——反方向的坑在 7.2 的注解小节处理。

让注解自动生效：JSR-305 与严格模式

逐个补注解是精细活，工程化的一步是让全库的注解一夜生效。Java 生态的 JSR-305 标准定义了 Nullable 与 NonNull 的规范注解，很多知名库（Guava、Retrofit、OkHttp 的部分版本）在字节码里带着它们。Kotlin 编译器支持按 JSR-305 严格解释这些注解：构建脚本加编译参数（freeCompilerArgs 加 Xjsr305 strict，新版本用 Xjs-spec 严格模式），带注解的 Java 类型在 Kotlin 眼里直接变成确定的非空或可空类型——平台类型的存量瞬间缩小一圈。严格模式的代价是行为变化（原本宽松放行的调用点可能开始报错），建议配合基线分批启用：先 warn 级别观察、再 strict 收紧——这延续了第 7 章一贯的渐进哲学。

第三个值得知道的工具是契约（contract）：Kotlin 函数可以用 contract 向编译器声明行为约定，最常见的就是"这个函数返回真则参数非空"：


// 标准库的实现示意
public inline fun <T, R> T?.let(block: (T) -> R): R {
    contract { callsInPlace(block, InvocationKind.EXACTLY_ONCE) }
    return block(this!!)
}

自定义判空函数（如 fun String?.isBlankOrNull()）配上 returns-true-implies-nonnull 契约后，if (s.isBlankOrNull()) ... else s.length 的 else 分支里能享受智能转换——没有契约时自定义判断函数之后的智能转换是失效的。写公共防御函数的团队值得掌握这一手，它让"自家的 isNotNull 检查"与语言内置检查同权。

常见问题

问：项目里平台类型多到清不完，从哪里下手能最快降低 NPE？
按崩溃数据倒推优先级。第一步，拉崩溃平台近九十天的 NPE 堆栈，归并到 Java 边界调用点（堆栈里有 Java 类名的那批）。第二步，前十个高频调用点各写一个门面函数完成可空判决（本节的收容模式）。第三步，把门面函数的判决结果沉淀成自家 Java 类的注解，一次性覆盖全部调用点。这个循环跑两轮，边界 NPE 通常降一个数量级——关键是用事故频率决定还债顺序，而不是按目录顺序扫。

问：Java 侧没有注解、也改不了（闭源 SDK），还有别的防线吗？
有，三层。最外层是门面收容（本节主体）；中间层是防御家族——对 SDK 返回值统一套 orEmpty、isNullOrEmpty 检查，宁可把"可能为空"高估；最内层是运行时断言——把 SDK 返回值立即赋给显式声明的非空变量，让编译器插入的 Intrinsics 断言把违约值当场拦下（异常栈直指边界行，而不是三层调用之外）。闭源 SDK 的另一个实践是写集成测试专门打"空返回"路径，把 SDK 文档里的"may be null"注释翻译成可执行的用例。

问：Kotlin 调 Java 的 getter 与属性访问，行为一致吗？
一致且自动——Java 的 getX() 与 isX() 在 Kotlin 里可以直接用属性语法访问（javaBean.name 对应 getName()）。要注意的只有两点：名字冲突（Java 同时有 getName() 与 name() 时需要显式调用方法形式）与可空性（属性语法不改变平台类型本质——val n: String = javaBean.name 看起来是属性赋值，实际仍是平台类型判决，该问号还得问号）。语法糖不豁免边界纪律。

本节要点回顾

平台类型是制度性缺口：Java 无可空信息，Kotlin 标记为"感叹号类型"放行，风险沿表达式传播；
击穿形态有欺骗性：代码长得像受保护的 Kotlin，实际裸奔在 Java 边界——崩溃堆栈会误导围观者；
注解是根本补法：Nullable 与 NonNull 家族让 Java 自报可空性，NonNull 还能换来边界断言快速失败；
声明收窄当场终结平台类型：显式问号或 orEmpty 家族，接收点一行完成判决；
架构收容进 data 层：平台类型不出数据层，domain 与 ui 永远是确定类型，审查聚焦一处；
映射差异顺手记：集合视角、关键字转义、检查异常穿透、静态成员访问——迁移期的暗雷清单。

单点防御讲完，下一节处理边界本身：混合项目怎么渐进迁移、每步怎么验收、以及什么时候应该停止。

作者与出处

原作者：灏天文库

来源：灏天文库

整理：灏天文库整理

由灏天文库平台收录，内容或由平台用户上传，仅供学习交流