Lambda 语法本身只有几个点，但语法题面试有个特点：答对了加分有限，答错了直接暴露基础不稳。真正的考点集中在三个容易混淆的细节与一个作用域问题上：尾随 lambda 与括号 lambda 的选择、it 与具名参数、Lambda 中的 return（非局部返回）语义、以及嵌套时的 it 覆盖。这四项讲清，语法题就稳了。
先把结论放在前面：Kotlin 的 Lambda 有两种传参形式——括号形式 foo(a, b) { ... }（Lambda 在括号内，作为最后一个参数）与尾随形式 foo(a, b) { ... }（Lambda 写在括号外）。当函数只有一个 Lambda 参数时，两者等价；当有多个参数时，尾随形式只能用于最后一个参数。Lambda 体里的 return 是非局部返回——它从定义它的那个函数返回，而不是从 Lambda 返回，因此只有 inline 函数里的 Lambda 才允许非局部返回，普通函数里的 Lambda 用 return@label 跳转。
机制拆解
先讲 it 的来源。Lambda 如果只有一个参数，编译器隐式命名为 it；有多个参数时必须用 it 之外的名字（具名参数写法 x, y -> 或 { item, index -> }）。这就是嵌套 Lambda 的坑：内层的 it 会遮蔽（shadow）外层的 it，两者类型可能不同，编译器不会报错——因为它解析到的是最近的那个 it。在 Android 的监听器嵌套场景（item 点击里再注册监听）这个坑非常容易踩。
再讲返回值类型。Lambda 的返回类型由最后一行表达式的值推断（块式 Lambda），或由参数列表箭头后的类型声明（{ x: Int -> ... } 显式指定）。如果 Lambda 需要返回 Unit 却写了有值的表达式，Kotlin 会把它变成"最后一个表达式被丢弃"而不是报错——这是 Kotlin 特有的宽松处，也是"Lambda 里最后写了个多余调用"能通过编译的原因。
非局部返回是本篇最重要的机制。函数 inline fun run(f: () -> Unit) 里，f 的 Lambda 体里写 return 会从 run 返回（因为 Lambda 被内联展开到了 run 的调用点）。而如果是非 inline 的普通函数，Lambda 会被包装成 Function0 对象，此时 return 没有合法的返回目标，编译器只能允许 return@label 形式（跳回 Lambda 末尾）。这个差异解释了为什么 Android 上很多带回调的 API 需要把宿主函数标成 inline。 Android 里 View.setOnClickListener 的 OnClickListener 是普通接口（不是函数类型），所以 onClick 里用 return 就是从 onClick 方法返回，而不是从 onClickListener(...) 返回——容易误解。Kotlin 的 View.doOnClick 扩展函数用 inline 包装了它，才能支持在点击事件里 return@doOnClick。
这些坑的正确绕法
最常见的坑是嵌套 Lambda 里多个 it 重名，引用错对象且编译器不报错。 表现是内层 Lambda 想用外层的那个值，却引用到了内层的 it，类型不同时会编译报错（能发现），类型相同时（比如都是 String）就悄悄取错了值。修法有两条：①给参数具名——setOnClickListener { v -> ... }、forEach { item -> ... }，不要依赖 it；②嵌套时给外层用明确名字。Android 上尤其要注意 ViewHolder 绑定里嵌套监听器的写法。
其次是把 Lambda 里的 return 理解错了作用域，导致代码提前结束。 表现是在 forEach（inline）里写 return，整个外层函数直接返回，而不是"跳过这个元素继续下一个"——这与 Java 里 return 的直觉一致，但与"跳过当前项"的意图不同。修法是明确目标：跳过当前元素用 for + continue；提前结束整个流程才用 return；只是跳出 Lambda 用 return@forEach。
还有一个更隐蔽的坑：把 Lambda 传给非 inline 的高阶函数时，误以为 return 也能直接用。 表现是把回调写成普通函数参数（非 inline），Lambda 里写 return 后编译报错（"returning type Unit is not allowed"），或者为了绕过而把 return 改成 return@label，结果函数返回值语义变了。修法是给宿主函数加 inline（函数体小的情况下），或改用具名 label 明确跳转目标。
代码里见真章
看一段能直接跑的代码，把上面的机制落到具体写法上：
// 1) 两种传参形式：单个 lambda 参数时等价
fun withTimeout(t: Long, block: () -> Unit) {
}
withTimeout(100) {
doWork() } // 尾随形式（更常用）
withTimeout(100, {
doWork() }) // 括号形式
// 2) 多个参数时，尾随形式只能配最后一个
fun connect(host: String, port: Int, retry: Boolean, onFail: (String) -> Unit) {
}
connect("h", 80, true, {
msg -> log(msg) }) // 只能用括号
connect("h", 80, true) {
msg -> log(msg) } // 尾随：retry 必须在括号里给值
// 3) it 遮蔽：编译通过，取错值
listOf("a", "b").forEach {
outer ->
listOf(1, 2).forEach {
inner ->
// 若这里用 it，拿到的是 Int 的那个，不是外层的 String
Log.d("t", "$outer vs ${it}") // 用 outer 明确，避免 it
}
}
listOf("a").forEach {
v -> // 反例 vs 正例：具名
listOf(1).forEach {
i -> Log.d("t", "$v-$i") }
}
// 4) 非局部 return：inline 才允许
inline fun runFast(block: () -> Unit) {
block() }
fun runSafe(block: () -> Unit) {
block() } // 非 inline
fun t1() {
runFast {
if (x()) return; doMore() } } // return 从 t1 返回 —— 合法
// fun t2() {
runSafe {
if (x()) return; doMore() } } // 编译报错
fun t3() {
runSafe {
if (x()) return@runSafe; doMore() } } // 只能跳回 lambda 末尾
// 5) 显式 label：嵌套时看得懂跳去哪
fun t4() {
runSafe outer@{
listOf(1, 2, 3).forEach inner@{
if (it == 2) return@inner else ok(it) }
return@outer
}
}
// 6) Lambda 的返回类型由最后一个表达式推断
val f: (Int) -> String = {
n -> if (n > 0) "正" else "非正" } // 显式类型
val g = {
n: Int -> n.toString() } // 最后一个表达式定类型
// 块式 lambda 写多余的最后一句会被丢弃（Kotlin 特有），不报错
这段代码值得盯三处：第一处，第 3 段把"it 遮蔽"与"具名参数"两种写法并列，并注释说明内层 it 是 Int 而不是外层的 String；第二处，第 4 段用 t1/t2/t3 三个函数把"非局部 return 的 inline 前提"演示清楚，t2 那一行被注释掉正好是反例；第三处，第 5 段的 outer@/inner@ 显式标签，是嵌套跳转的标准写法。
这题在面试里怎么问、怎么答
"Lambda 里的 return 到底返回到哪里？"答：从定义 Lambda 的那个函数返回，这叫非局部返回；但这只在 Lambda 被内联（宿主函数是 inline）时成立，否则编译器没有合法的返回目标。非 inline 时只能用 return@label 跳回 Lambda 自身末尾。
"it 是怎么来的？什么时候没有？"答：编译器为单参数的 Lambda 隐式命名 it。有多个参数、或显式写了参数名（或类型）时就没有 it。另外在有嵌套 it 时，内层的 it 遮蔽外层——这是建议具名命名的根本原因。
"尾随 lambda 和括号 lambda 什么时候不能换？"答：当函数有多个参数、且 lambda 不是最后一个时；或者存在多个 lambda 参数时，尾随形式只能写最后一个。另外尾随形式要求 lambda 体是一个块，不能写成带括号调用的形式。
"使用中遇到过什么问题？"案例一：ListAdapter.onBindViewHolder 里给 item 视图设置点击监听，监听里又嵌套了一个 forEach，内层用了 it 引用外层的 item，导致取错对象；修复为内外都具名。案例二：一个工具函数用非 inline 的函数参数，回调里写 return 想提前结束，结果被改成 return@label 后语义变了，外层继续执行；修复为把宿主函数改为 inline。
再补一个工程上值得讲清的一点：Android 上 doOnClick/doOnTextChanged 这类 inline 扩展值得优先用。 androidx 的 View.doOnClick 是 inline + crossinline 实现的，它把点击监听包了一层，既避免了重复 setOnClickListener 的内存泄漏（弱引用持有 View），又支持在监听里 return@doOnClick 提前退出。相比手写 setOnClickListener { v -> ... }，它解决了两个实际问题：监听器持有 View 造成的泄漏、以及无法用 return@ 语义。这说明"AndroidX 里很多看起来啰嗦的 API，是为了解决 inline 与生命周期问题"，能主动说出这一点的候选人会显得真的读过源码。
给正在准备面试的你
把这题画成一张"Lambda 传参与返回"的四格图。第一行讲传参形态：左边"括号形式 f(a, b) { }"，右边"尾随形式 f(a, b) { }"，中间箭头标"仅当 lambda 是最后一个参数时等价"。第二行讲返回语义：左边"inline 宿主 → return 非局部返回，从外层函数返回"，右边"非 inline 宿主 → return@label 跳回 lambda 末尾"，中间用一条竖线分隔并标"编译期行为不同"。图下方补两个"避坑"标签：it 遮蔽（写"嵌套时具名"）、返回类型由最后一行推断（写"块式 lambda 的宽松处"）。这张图能把语法题的所有追问答完。
再补工程案例与踩坑——应用落点是把项目里嵌套 Lambda 里的 it 逐个改成具名参数；把非 inline 但 Lambda 里需要 return 的宿主函数改为 inline（函数体小的情况下）；Android 上把裸 setOnClickListener 换成 doOnClick 解决泄漏与 return@ 语义。
复习时别孤立刷题：高阶函数——Lambda 是"传行为"的载体，高阶函数是"接收行为"的机制，两者是同一条线的两端。
划两句重点：尾随 lambda 只对最后一个参数成立；Lambda 里的 return 是非局部返回，仅 inline 宿主允许；it 会被内层遮蔽，一律具名；块式 Lambda 返回类型由最后一个表达式推断，多余的最后一句会被丢弃。
下一篇聊 inline 内联函数：高阶函数零开销的秘密——沿着今天这条主线继续往前走。
如果这篇文章对你有帮助，欢迎点赞、在看、转发三连。你的支持就是这个系列持续更新的动力。
「Android软件开发面试·从入门到精通」连载系列
上一篇：高阶函数：函数作为参数与返回值
下一篇预告：inline-内联函数：高阶函数零开销的秘密
有任何问题欢迎在评论区留言交流。
