Lambda 表达式

是什么，为什么存在

Lambda 表达式（lambda expression）是用花括号写出的函数字面量。它没有声明名称，却能生成一个可以调用的值。Kotlin 把函数作为 一等函数（first-class function） 处理，因此这个值可以存入属性和集合、作为实参传递，也可以由另一个函数返回。

函数类型（function type） 描述这个值的调用契约。(Order) -> Boolean 接收一个 Order 并返回 Boolean，() -> Unit 不接收参数且只产生副作用，suspend (Request) -> Response 则表示可挂起调用。静态类型让高阶函数能够接收行为，同时让编译器检查参数与结果。

Lambda 解决的是“把一段行为交给另一段代码”的问题。集合操作用它定义筛选与转换规则，事件 API 用它保存回调，资源函数用它包住一段受控操作，构建器用它提供局部配置语法。行为只用一次或紧邻调用点时，lambda 通常比单独声明函数更紧凑。

Lambda 并不自动带来纯函数、惰性求值、并发安全或更高性能。它只是一种函数值写法；是否立即调用、调用几次、在哪个线程调用、能否保存，以及异常由谁处理，都由接收它的 API 决定。阅读调用点时，函数参数的契约比花括号本身更重要。

工作原理

函数类型规定调用形状

普通函数类型写成 (P1, P2) -> R。参数类型位于箭头左侧，结果类型位于右侧；参数名称可以写进类型中帮助阅读和 IDE 提示，但不影响类型兼容性。函数类型本身可空时必须加括号，例如 ((String) -> Int)?，这与返回可空值的 (String) -> Int? 不同。

带接收者的函数类型在参数列表前增加接收者，例如 ReceiptBuilder.() -> Unit。调用这种值时要提供一个 ReceiptBuilder；lambda 体内，该对象成为隐式 this。可挂起函数类型带有 suspend，只能在允许挂起调用的上下文中执行。

常见形状如下：

函数参数具有逆变方向，结果具有协变方向。能处理任意 Number 并返回 String 的函数，也能放到只会传入 Int、只要求得到 Any 的位置。判断兼容性时，要问候选函数能否接住调用方可能传入的每个值，以及它的结果是否满足调用方承诺的类型。

预期类型驱动推断

Lambda 的完整形状是 { 参数 -> 函数体 }，最后一个表达式成为结果。若赋值目标或函数形参已经给出预期类型，参数类型通常可以省略。只有一个可推断参数时，还可以省略参数列表与箭头，并用隐式名称 it。

推断需要上下文。单独写 { value -> value.length } 时，编译器不知道 value 的类型；把它赋给 (String) -> Int，或传给形参类型明确的函数后，String 才能确定。重载让预期类型不唯一时，应写出变量类型、参数类型或具名实参，缩小解析空间。

Lambda、匿名函数和函数引用都能产生函数类型值。::parseRecord 引用已有函数，parser::parse 把接收者绑定到特定对象，Record::id 可以把属性读取当作函数传递。已有声明正好表达意图时，函数引用能保留名称；需要捕获局部配置或组合几步操作时，lambda 更直接。

调用与尾随 lambda

函数值可用普通调用语法 predicate(order) 执行，也可以显式写成 predicate.invoke(order)。前一种更像普通函数，通常更易读。调用方无法仅凭语法知道实现来自 lambda、匿名函数、函数引用还是实现了调用约定的对象。

当函数的最后一个形参是函数类型时，对应的 lambda 实参可以移到圆括号外，这叫尾随 lambda（trailing lambda）。如果它是唯一实参，圆括号也可以省略。该规则只改变调用语法，不改变参数顺序，也不会自动把任何花括号变成异步任务或新的语言结构。

尾随位置始终对应最后一个形参。一个 API 若有多个函数形参且都带默认值，load { handle() } 可能绑定到最后的失败回调，而不是前面的成功回调。此类调用应写具名实参，让回调角色在源码中可见。

捕获形成闭包

Lambda 可以访问定义位置可见的局部变量。函数值与这些外部绑定共同形成 闭包（closure） 。Kotlin 允许 lambda 读取并修改捕获的 var，所以同一作用域创建的多个 lambda 可能共享一份不断变化的状态。

捕获不是并发原语。多个线程调用同一个闭包时，普通 var 的读写不会因此变成原子操作，也不会自动建立可见性保证。跨线程保存回调时，状态应由锁、原子类型、消息传递或单线程所有权保护，而不是依赖 lambda 的简短外观。

长期保存的 lambda 还会延长其捕获对象的可达时间。只需要请求 ID 的监听器若捕获整个请求上下文，就可能连带保留缓存、缓冲区或服务引用。先提取所需的小型稳定值，再创建长期回调，可以让生命周期边界更清楚。

接收者与 SAM 是两种契约

带接收者的 lambda（lambda with receiver） 把一个对象作为隐式 this，适合表达层级构建或在受限对象上执行一组操作。它仍是普通函数值，不会增加解析器，也不会自动限制嵌套接收者。复杂 DSL 的作用域控制属于 @DslMarker 与专门的 DSL 设计。

函数式接口（functional interface）使用 fun interface 声明，并且只有一个抽象方法。 SAM 转换（SAM conversion） 可以把签名匹配的 lambda 转成这种名义接口的实例；Kotlin/JVM 也支持 Java 单抽象方法接口。接口可以拥有名称、非抽象成员和独立扩展，普通函数类型则只表达输入与结果。

若 API 只需要调用某段行为，优先使用函数类型，必要时用 typealias 提供领域名称。若调用方必须承诺一个有身份的领域角色，或契约还包含其他成员，fun interface 更合适。两者看起来都能接收 lambda，但它们不是可随意互换的 API 边界。

示例

下面四个程序分别展示函数类型、闭包状态、接收者和返回控制。它们都是独立文件，已使用 Kotlin 2.4.10 编译器编译，并在 JRE 21 上运行；紧随代码的输出来自实际执行。

把筛选规则作为值传递

第一个程序声明一个明确的谓词类型，并把同一个高阶函数分别与变量 lambda 和尾随 lambda 一起使用。Order::id 则把属性引用作为映射函数。

selectIds 决定何时以及对哪些元素调用谓词；lambda 只提供判断规则。第一处调用把函数值放在圆括号内，第二处把最后一个 lambda 移到括号外，两者传递的是同一种 (Order) -> Boolean 契约。

属性引用 Order::id 的形状可视为 (Order) -> String。它接收一个未绑定的 Order，返回该实例的 id。如果改为 orders.first()::id，得到的是已绑定属性引用，不再需要 Order 参数。

每个工厂调用拥有独立状态

第二个程序返回捕获 next 的函数。两次调用 ticketSequence 会创建两份状态，而给同一函数值增加别名不会复制状态。

fun ticketSequence(prefix: String): () -> String {
    var next = 1
    return { "$prefix-${next++}" }
}

fun main() {
    val web = ticketSequence("WEB")
    val batch = ticketSequence("BATCH")

    println(listOf(web(), web(), batch(), web(), batch()))

    // 别名仍指向同一个闭包。
    val sameWeb = web
    println(sameWeb())
}

[WEB-1, WEB-2, BATCH-1, WEB-3, BATCH-2]
WEB-4

web 与 batch 来自不同工厂调用，因此各自从 1 开始。sameWeb 只是复制函数值引用；它调用后得到 WEB-4，证明它与 web 操作同一个捕获状态。

这种小型状态机适合只有一个操作的接口。若状态需要重置、检查、持久化或并发控制，带明确方法和所有权的类通常更容易维护。函数值隐藏了状态表示，却没有消除状态设计。

用接收者限定配置词汇

第三个程序接收 ReceiptBuilder.() -> Unit。调用块中的 item 会解析到隐式 ReceiptBuilder 接收者，入口函数则负责创建、调用并最终构建结果。

class ReceiptBuilder {
    private val lines = mutableListOf<String>()

    fun item(name: String, cents: Int) {
        require(name.isNotBlank()) { "name must not be blank" }
        require(cents > 0) { "cents must be positive" }
        lines += "$name=${cents}c"
    }

    fun build(): String = lines.joinToString("|")
}

fun receipt(block: ReceiptBuilder.() -> Unit): String {
    val builder = ReceiptBuilder()
    builder.block()
    return builder.build()
}

fun main() {
    val summary = receipt {
        item("coffee", 450)
        item("cake", 325)
    }

    println(summary)
}

coffee=450c|cake=325c

builder.block() 同时完成两件事：调用函数值，并把 builder 作为接收者提供给它。也可以把接收者函数值写成 block(builder) 调用，但点号形式更能显出接收者关系。

块内简洁的调用来自静态接收者类型，不是任意名称查找。公开给 ReceiptBuilder 的成员都会成为块内词汇，因此构建器应保持狭窄，并在返回最终结果前完成校验和所有权转换。

区分非局部返回与带标签返回

第四个程序展示两种不同目标。传给内联 forEach 的裸 return 会从 firstReady 返回；return@transform 只结束本次 mapNotNull 调用。

fun firstReady(records: List<String>): String? {
    records.forEach { record ->
        if (record.startsWith("ready:")) {
            // forEach 是内联函数，因此这里返回 firstReady。
            return record.removePrefix("ready:").trim()
        }
    }
    return null
}

fun normalized(records: List<String>): List<String> =
    records.mapNotNull transform@{ record ->
        val value = record.substringAfter(':', missingDelimiterValue = "")
        // 带标签返回只跳过当前元素。
        if (value.isBlank()) return@transform null
        value.trim().uppercase()
    }

fun main() {
    val records = listOf("skip", "ready: alpha", "ready: beta", "bad:")

    println(firstReady(records))
    println(normalized(records))
}

alpha
[ALPHA, BETA]

裸 return 能穿过 forEach，是因为标准库在调用点内联了这个 lambda。把同样的 lambda 传给普通非内联函数会编译失败；编译器不能让稍后保存或间接调用的回调返回一个已经不存在的调用帧。

return@transform null 的目标由显式标签确定。使用调用名称的隐式标签 return@mapNotNull 也可行，但在嵌套调用或同名函数较多时，显式标签更易审查。只需要提前结束遍历时，普通 for 循环往往最直接。

陷阱

修复方法： 先确认接收函数是否内联以及 lambda 是否可非局部返回。只结束本次 lambda 调用时使用 return@label，局部返回逻辑复杂时使用匿名函数，只想结束遍历时考虑普通循环。不要仅凭 forEach 看起来像循环就猜测控制流。

修复方法： 嵌套后立即给参数命名，例如 order 与 lineItem。单参数、单表达式且含义显然时再使用 it。审查时逐个标出每个名称的静态类型，而不是从属性名推测它指向谁。

修复方法： 需要独立状态时，为每个所有者调用一次工厂；需要快照时，先复制出本轮不可变值；有意跨线程共享时，明确同步策略。用交错调用和并发测试验证所有权，不要只逐个调用每个回调一次。

修复方法： 对角色不同的回调写具名实参，例如 onSuccess = { ... } 与 onFailure = { ... }。设计新 API 时，避免让多个同形状回调仅靠位置区分；名义接口或事件对象可以让含义进入类型和名称。

修复方法： 只描述调用形状时使用函数类型；typealias 仅提供别名，不创建新类型；需要名义身份或额外成员时使用函数式接口。修改公开 API 前，同时编译 Kotlin 与 Java 调用方，而不是只看 lambda 调用是否仍然简短。

延伸阅读

以下链接指向 Kotlin 官方文档的源文件。它们分别覆盖函数类型与 lambda 语法、内联与非局部控制流、函数式接口及 SAM 转换，以及函数引用。

• Kotlin 高阶函数与 lambda 文档源文件
• Kotlin 内联函数文档源文件
• Kotlin 函数式接口文档源文件
• Kotlin 函数引用文档源文件