评估 Kotlin 为 if-else 增加语法糖的必要性

先看一段常见代码：条件成立时生成一个值，否则保持为空。

fun resolve(enabled: Boolean): String? {
    return if (enabled) {
        "ready"
    } else {
        null
    }
}

按本文讨论的候选规则，表达式位置可以省略 else，未命中时得到 null。于是代码可以简化为：

fun resolve(enabled: Boolean): String? =
    if (enabled) {
        "ready"
    }

条件为真时返回 String，条件为假时返回 null，整体静态类型是 String?。在未启用该候选特性的 Kotlin 编译器中，缺少 else 的表达式通常会得到类似诊断：

error: 'if' expression must have both main and 'else' branches.

这种写法省掉的是“失败时没有结果”的显式分支，并不会替开发者决定两个分支中该执行哪一个。对于分支都有明确业务含义的普通二选一，显式 if-else 仍然更清楚。

掘金热榜文章《Kotlin 又要加语法糖了：这次轮到 if-else》提供了讨论入口。 但该资料只有标题和链接，没有官方提案编号、候选语法全文、评审结论或编译器版本，因此不能把上述写法直接称为已经发布的功能。下文以“省略 else、缺失分支表示缺省值”为分析模型，具体规则和状态应以官方提案及对应版本编译器为准。

if 表达式与语句的边界

Kotlin 的 if 既是控制结构，也可以作为表达式返回分支值，后者是其区别于 Java if 语句的重要特征之一。 两种用法的约束并不相同。

如果 if 只作为语句使用，结果不会被消费：

if (enabled) {
    notify()
}

这种写法不需要产生可供赋值或返回的值。但如果把 if 放在赋值、返回语句等需要结果的位置，两个分支就必须共同形成一个可用结果：

val status = if (enabled) {
    "ready"
} else {
    "disabled"
}

候选规则真正要解决的是后一种场景：允许省略缺失分支，但必须同时回答“缺失分支产生什么”和“整个表达式是什么类型”。

较合理的缺省值模型是 null：

写法	条件为真	条件为假	推断结果
if (flag) "ready" else null	"ready"	null	String?
if (flag) "ready" else "idle"	"ready"	"idle"	String
候选写法 if (flag) "ready"	"ready"	null	String?

如果上下文明确要求非空类型，编译器应当拒绝这类代码，而不是把 null 强行放入 String：

val invalid: String = if (flag) {
    "ready"
}

Unit 也能作为另一种候选语义，但它更适合现有的语句式 if。如果缺失分支统一产生 Unit，那么这个特性在返回值场景中的实际收益会非常有限。上下文驱动的推断则更危险：相同的表达式可能被推断成不同类型，错误容易延迟到调用方。因此，相较于静默改变类型，“缺失即 null，并完整反映到可空类型中”的模型更直接，也更安全。

显式类型仍然值得保留：

fun resolve(enabled: Boolean): String? =
    if (enabled) {
        "ready"
    }

这样既明确了缺失分支的语义，也避免公开 API 的返回类型完全依赖推断。

嵌套、else-if 与副作用

省略 else 后，嵌套规则必须保持可预测。例如：

val result = if (outer) {
    if (inner) {
        "both"
    }
} else {
    "outer false"
}

如果内层 if 的缺失分支同样表示 null，那么结果分别对应：

outer	inner	result
true	true	"both"
true	false	null
false	无关	"outer false"

这种规则没有引入新的运行机制，却要求读者从嵌套结构中辨认每个 if 的缺失分支。对于更深的结构，阅读成本会迅速上升。

else if 链也需要明确终端分支的规则：

val grade = if (score >= 90) {
    "A"
} else if (score >= 60) {
    "B"
}

在本文采用的模型中，两个条件都不满足时得到 null。但 else if 本身是一条嵌套的 if，规范必须说明省略规则是只作用于最外层，还是递归作用于终端分支。否则，不同实现可能得到不同结果。

作用域原则上不需要变化。候选写法只是省掉一个恒为 null 的分支，不会扩大局部变量的作用域。真正需要保持一致的是求值顺序：条件只计算一次，只执行被选中的分支，缺失分支没有代码可执行，异常也应沿原有路径传播。

var calls = 0

val value = if (calls++ == 0) {
    calls++
} else {
    null
}

如果候选写法只是 if 与 else null 的等价展开，那么它与上面的代码应具有相同的条件求值、分支执行和异常传播行为。编译器还需要处理尾随 lambda、重载解析和语句／表达式上下文之间的歧义。

语法变化在 JVM 上的形态

这类改动首先发生在源码、类型推断和编译器前端，不必天然对应新的 JVM 指令。如果实现先把候选写法展开为现有的 if 与 else null，最终字节码可能完全一致。

Kotlin 顶层函数已经展示了源码结构与 JVM 结构之间的映射关系：顶层函数会进入以文件名为基础的生成类，并成为静态方法；@file:JvmName 还可以改变生成类名。 因此，检查新语法是否真的“零成本”，不能只看源码少了几行，还要比较生成类、方法、元数据和指令。

对于下面的顶层函数：

fun resolve(enabled: Boolean): String? =
    if (enabled) {
        "ready"
    }

至少需要核对三件事：

• 生成的方法名称、参数列表和返回类型是否与旧写法一致；
• Kotlin 元数据中的可空信息是否一致；
• 条件分支与 null 返回值的指令是否等价。

这也是“语法糖”这一说法需要谨慎使用的原因。如果实现仅做等价展开，它可以被称为语法糖；如果它允许过去非法的表达式成立、改变推断类型或影响公开签名，它就是语言表面和类型系统层面的变化，而不只是书写形式变化。

候选语法适合哪些代码

候选写法最有价值的地方，是消除已经表达清楚、却仍需重复书写的缺省分支。

场景	建议写法	判断
条件成立才赋值，否则为空	候选 if，并明确返回 String?	缺失值语义清晰时合适
简单二选一，两边都有业务含义	显式 if-else	不应为了少写 else 而隐藏分支
条件成立时计算新值	普通 if-else 或 when	新写法并没有提供计算能力
可空对象为空时使用默认值	Elvis 操作符 ?:	通常更直接
可空对象存在时才转换	安全调用配合 let	适合局部作用域操作
多分支选择	when	更容易表达完整决策树
集合为空时提供默认集合	ifEmpty	专门处理空集合或空文本
文本为空白时提供默认文本	ifBlank	专门处理空白字符串
条件成立时保留原值	takeIf／takeUnless	适合谓词筛选，不负责任意转换

Elvis 操作符适合“值本身可空，为空时取默认值”的情况：

val name = rawName ?: "unknown"

右侧只在左侧为 null 时求值，这与普通条件分支的求值时机不同。 当代码只是需要“空值兜底”时，Elvis 通常比 if 更短，也更容易看出默认值含义。

安全调用配合 let 适合在对象非空时执行一段局部操作：

val length = name?.let {
    println("Name is $it")
    it.length
}

let 是标准库扩展函数，作用域内通过 it 暴露接收者，返回代码块最后一个表达式的值；与安全调用组合时，接收者为 null 就不会执行代码块。 它和候选 if 的区别在于：let 判断的是可空对象是否存在，候选 if 判断的是任意布尔条件。

takeIf 和 takeUnless 适合筛选原值：

val positive = value.takeIf { it > 0 }
val notEmpty = value.takeUnless { it.isEmpty() }

它们在条件成立时返回原对象，否则返回 null。如果需求是“条件成立时计算另一个值”，则仍需要显式转换或 if：

val doubled = value.takeIf { it > 0 }?.let { it * 2 }

集合和文本还有更贴近领域的标准库写法：

val safeList = list.ifEmpty {
    arrayListOf("空数据")
}

val safeText = text.ifBlank {
    "空数据"
}

ifEmpty 和 ifBlank 的默认内容由 lambda 提供，适合在集合为空或文本为空白时生成缺省值。 它们不能替代任意布尔条件判断，但可以避免业务代码重复构造默认集合或默认字符串。

多分支决策则更适合 when：

val level = when {
    score >= 90 -> "A"
    score >= 60 -> "B"
    else -> "idle"
}

when 能把条件、结果和兜底分支放在同一层级，也更适合密封类型、枚举等需要明确覆盖关系的场景。候选 if 的优势只有一个：缺失结果确实可以自然表示为 null。如果缺失结果没有明确含义，强行省略分支只会隐藏决策。

在引入新语法前，也应先检查现有语言能力是否已经覆盖需求。Kotlin 的命名参数、默认参数和数据类可以减少构造对象时的样板代码，例如：

data class Person(
    val name: String,
    val age: Int = 0,
    val gender: Int = 1,
    val height: Int = 0,
)

val person = Person(name = "taylor", age = 50)

这类既有能力比增加一种条件写法更稳定，因为它们不要求团队升级语言规则，也不需要重新判断分支缺失的含义。

公开函数需要单独检查

候选写法最容易被低估的风险是公开函数的返回类型从非空变为可空。

fun resolve(enabled: Boolean) =
    if (enabled) {
        "ready"
    } else {
        "disabled"
    }

旧代码的返回类型是 String。如果改写为：

fun resolve(enabled: Boolean) =
    if (enabled) {
        "ready"
    }

在隐式 null 模型下，返回类型会变成 String?。即使函数体少了一行，调用方却可能需要新增空值处理，原有 Kotlin 调用代码也可能无法再直接访问非空成员。

更稳妥的公开 API 写法是显式声明类型：

fun resolve(enabled: Boolean): String? =
    if (enabled) {
        "ready"
    }

如果旧代码本来就是：

fun resolve(enabled: Boolean): String? =
    if (enabled) {
        "ready"
    } else {
        null
    }

那么改写前后的公开类型可以保持一致，升级风险会小得多。

Java 调用者不直接使用 Kotlin 的源级写法，却仍然会受到方法签名、空值元数据和生成字节码的影响。顶层函数在 Java 中通常通过类似 ResolveKt.resolve(flag) 的静态方法调用。 Java 类型系统不会自动执行 Kotlin 的非空约束，因此 Java 调用方仍需自行处理可能的 null。

升级前要把源码、API 和产物分开看

兼容性不能简单归结为“只是语法糖，所以没有影响”。源码级、API 级和 ABI 级风险关注的对象不同，应分别验证。

检查层次	主要风险	建议验证
源码兼容性	新规则与嵌套 if、else if、尾随 lambda、重载或表达式上下文产生歧义	编译全部现有源码，确认旧代码仍按原语义解析
公开 API	推断返回类型、可空标注、泛型推断发生变化	对比公开函数签名及 Kotlin 元数据
字节码与 ABI	方法描述符、生成类名、元数据或内联函数体变化	使用 javap 等工具比较改写前后的产物
Java 互操作	Java 调用者面对新的空值结果或不同签名	从 Java 编译并调用改写后的 API
工具链	IDE、Gradle、Maven、命令行编译器及语言版本不一致	固定并记录完整工具链版本
多平台后端	Kotlin/JVM、JavaScript、Native 的规则或产物不一致	在 common source 与各目标平台分别编译
混合版本模块	新模块调用旧模块，或旧编译器读取新元数据	建立新旧模块交叉依赖测试
行为兼容	条件、副作用、异常或嵌套求值顺序变化	为分支顺序和异常路径增加测试

源码兼容通常遵循“旧代码仍能编译且含义不变”的原则，但新增可选分支仍可能触碰语法边界。尤其是以下结构应进入回归样例：

if (outer) {
    if (inner) {
        consume()
    }
} else {
    fallback()
}

if (condition) {
    consume { payload ->
        process(payload)
    }
}

val value = if (condition) {
    calculate()
}

公开 API 则要重点比较显式和隐式类型：

// 改写前：String
fun oldApi(flag: Boolean) =
    if (flag) "yes" else "no"

// 改写后：String?
fun newApi(flag: Boolean) =
    if (flag) "yes"

两者在 JVM 返回类型描述符上可能都表现为 String，但 Kotlin 元数据中的可空信息不同。对 Kotlin 调用方而言，这已经是 API 变化；不能因为 JVM 描述符看起来相同，就认定二进制兼容。

如果候选写法最终只是展开为现有的 if 与 else null，并且显式返回类型保持不变，那么普通函数改写前后的字节码很可能高度一致。但这只是需要验证的假设，不是可以省略检查的结论。

公开 inline 函数还要单独测试。内联函数会把函数体传播到调用点，函数体、元数据以及调用方重新编译的时间都可能影响最终产物。混合版本模块则应验证：旧模块能否链接新模块，新模块能否调用旧模块，以及重新编译前后的内联调用结果是否一致。

行为兼容不能只检查最终返回值，还要检查：

• 条件表达式是否只执行一次；
• 未命中分支是否完全不执行；
• 选中分支的副作用顺序是否保持不变；
• 分支抛出的异常是否原样传播；
• 嵌套 if 的归属是否明确；
• else if 终端分支的缺省结果是否稳定。

用一组样例决定是否采用

读者可以先建立五类最小测试，而不是立即批量改写项目：

1. 条件命中时返回非空值；
2. 条件不命中时返回 null；
3. 条件或分支包含计数、写入等副作用；
4. 包含嵌套 if 和 else if；
5. 作为公开函数，由 Kotlin 与 Java 分别调用。

在支持候选特性的隔离分支上，应使用与项目匹配的编译器验证。先记录工具链：

kotlinc -version

使用命令行编译器构建样例：

kotlinc src/main/kotlin -d build/classes/kotlin/main

如果项目通过 Gradle 构建，则执行：

./gradlew compileKotlin

再检查生成类、方法和字节码。假设文件名为 Resolve.kt，顶层函数通常对应 ResolveKt：

javap -classpath build/classes/kotlin/main -p -v ResolveKt

改写前后的检查结果至少应并列记录：

• Kotlin 推断类型与显式 API 类型；
• 生成方法签名及空值元数据；
• 条件分支、返回 null 和异常路径的字节码；
• Java 调用结果；
• Kotlin/JVM、JavaScript、Native 的构建结果；
• IDE 对新语法的识别和诊断。

最后把候选写法与 when、Elvis、let、takeIf、ifEmpty 和 ifBlank 放在同一张表中比较。采用门槛可以归纳为四项：新写法是否明确表达缺省语义，是否比现有方案更容易阅读，是否保持公开类型不变，以及工具链成本是否可控。完成上述五类测试和产物对比后，再根据这些条件决定是否采用。社区将其称为“语法糖”，不足以单独构成升级成熟代码的理由。