Lambda 与函数式接口本身不难，难的是它背后那条线——从匿名内部类到 Lambda，从 Lambda 到方法引用，再到函数式接口的默认值方法、组合子、以及 Streams 里的归约思想。这条线串起来，Java 的"行为参数化"就讲清楚了；讲不清楚，就只是用过几个语法糖。
先把结论放在前面：函数式接口是只有一个抽象方法的接口，可以用 Lambda 或方法引用实现；Java 内置四个核心接口——Function<T,R>（有入参有返回值）、Consumer<T>（有入参无返回值）、Supplier<T>（无入参有返回值）、Predicate<T>（有入参返回布尔），其余接口基本都是这四者的组合或扩展。 Lambda 编译后不是执行动态查找，而是在类初始化时生成一个实现了目标接口的隐藏类，调用点是 invokedynamic + LambdaMetafactory 在首次执行时完成链接。
机制拆解
Java 8 之前要表达"把一段行为传进去"，只能写匿名内部类：新建一个类、覆盖方法、把外部变量变成字段。代码量大、可读性差。Lambda 把它简化成一段表达式，但它不是凭空来的——编译器会在编译期生成一个实现接口的类，字节码层面仍是接口 + 实现，只是这个实现类由编译器生成、通过 invokedynamic 在运行期首次链接时确定目标。
有两个细节能拉开区分度。第一，捕获语义：Lambda 只能捕获 effectively final 的局部变量（Java 8 起 final 修饰符可以省略，编译器做等价检查）。原因在字节码层面很直白——局部变量是栈帧上的槽位，Lambda 可能比原方法活得更久，栈帧销毁后槽位就没了，所以只能把值复制到生成的类里。 反过来，成员变量（this 引用）是天然 effectively final 的，可以直接在 Lambda 里访问。
第二，泛型擦除与桥接方法：Lambda 里的类型参数在运行时被擦除，所以 list.stream().map(s -> s.length()) 在编译后不知道具体元素类型，靠调用点的目标类型（目标类型推断）才能定型。这也是为什么 Lambda 不能赋值给 Object，也不能在完全没有目标上下文的地方写 x -> x + 1。
这些坑的正确绕法
最常见的坑是在 Lambda 里试图修改捕获的局部变量，编译期直接报错。 报错信息是 local variables referenced from a lambda expression must be final or effectively final，很多人在面试现场看到这个会以为是环境问题。 解法有两条：确实需要改就用 AtomicInteger 之类的可变引用类包一层；不需要改就确认这个修改本身就不该在 Lambda 发生，Lambda 适合做无副作用的转换，把副作用留给外面。
其次是 Lambda 里写长逻辑，可读性断崖式下降。 表现是十几行的 Lambda 嵌套三层 map/filter，调试时栈帧全是合成方法名，定位困难。这不是语法问题而是设计信号：超过五行的逻辑应该抽成方法，或者干脆用普通循环——Looper 场景下的列表遍历用 for 循环往往更合适，因为它没有中间集合开销。
还有一个更隐蔽的坑：在 Android 的低版本设备上用了 Java 8+ 的 Stream API，低版本运行时找不到类。 表现是低版本机型上启动即崩，堆栈里是 NoClassDefFoundError: java.util.stream.*。 原因在于 Stream 是 java.util.stream 下的类，Android 的 desugar 只能处理一部分语言特性（默认方法、静态方法、Lambda 可以 desugar），但新增的库类需要在 minSdk 足够高时才能直接用。 对策是用三选一：把 minSdk 提到 24 以上、用 D8 desugaring 支持的替代库（streamsupport 或 Kotlin 集合操作）、或者在低版本走普通循环分支。
代码里见真章
看一段能直接跑的代码，把上面的机制落到具体写法上：
// 四个核心函数式接口的典型用法
List<String> names = loadNames();
Function<String, Integer> len = String::length; // 方法引用
Consumer<String> log = s -> Log.d("list", s); // 无返回值
Supplier<List<String>> factory = ArrayList::new; // 无入参有返回值
Predicate<String> notEmpty = s -> !s.isEmpty(); // 返回布尔
// 组合：Predicate 有 and / or / negate，可以复用判定逻辑
Predicate<String> shortName = s -> s.length() <= 6;
Predicate<String> usable = notEmpty.and(shortName);
long count = names.stream().filter(usable).count();
// 注意：Lambda 只能读 effectively final 的局部变量
AtomicInteger index = new AtomicInteger(0);
List<String> numbered = names.stream()
.map(s -> (index.getAndIncrement() + 1) + ". " + s) // 副作用靠外部引用
.collect(Collectors.toList());
// 副作用不要藏在 Lambda 里（下面的写法会吞掉异常，且在主线程做 IO）
// bad : names.forEach(s -> saveToFile(s));
names.forEach(s -> Log.d("row", s)); // 好：只做轻量副作用
这段代码值得盯三处：第一处，String::length 这种方法引用与 s -> s.length() 等价，但更短、意图更清楚；第二处，AtomicInteger 演示了如何在 Lambda 里保留可变状态——这是绕过 effectively final 限制的正规做法；第三处，最后那个反面例子点出关键区别：Lambda 适合纯计算与轻量回调，把 IO、锁、耗时操作塞进去会让回调地狱更隐蔽。
这题在面试里怎么问、怎么答
"Lambda 的底层原理是什么？"分三步：编译器为每个 Lambda 生成一个实现目标接口的合成类；字节码里用 invokedynamic 指向 LambdaMetafactory.metafactory；首次执行时该指令完成方法句柄的链接并生成调用点，之后调用近乎虚方法开销。 补一句对比：匿名内部类在编译期确定，Lambda 在运行期首次链接，所以冷启动阶段会有一丝额外成本，热路径上没有差别。
"函数式接口怎么自定义？"写一个单抽象方法接口并标 @FunctionalInterface（这个注解让编译器帮你检查），实现可以用 Lambda 也可以用方法引用。 补上两个实战友好的设计：用 default 方法给接口加静态能力（比如给 Predicate 加一个 or 的静态组合方法），或者让接口成为参数的传递载体（interface Converter<T, R> { R convert(T in); }）。注意接口只能有一个抽象方法，default 与 static 方法不算。
"Lambda 比匿名内部类更快吗？"未必快。生成类的成本是一次性的，实例创建走同样路径；真正可能影响性能的是两点：一是单例式复用时，匿名内部类每次 new 都有对象分配，Lambda 若被提取为常量字段则可复用；二是装箱——Lambda 的 Function<Integer,Integer> 在参数为基本类型时会引入拆装箱，而 IntFunction 这类特化接口可以避免。 这两点讲清楚，比笼统说"Lambda 快"有说服力。
"使用中遇到过什么问题？"案例一：列表筛选逻辑在三个 Activity 里各写一遍，改需求要改三处；定位到匿名内部类无法复用；修复为提取成静态的 Predicate<User> 常量并配单测。 案例二：低版本机型上点击某个列表页闪退；定位到用了 List.sort 与 Stream 的 Comparator.comparing，堆栈是 NoClassDefFoundError；修复为抽一个工具方法在低版本走 Collections.sort 兼容分支。
再补一个工程上值得讲清的点：Lambda 捕获 this 意味着外部实例被延长了生命周期。Android 上更隐蔽的一种情形是把 View 传进 Lambda 交给一个后台任务持有，View 因此无法回收，Activity 销毁后内存里还留着整棵视图树——泄漏的是整个页面。 所以传给长生命周期回调（Handler 延迟消息、Rx 定时任务、静态集合）的 Lambda 里要避免捕获 Activity/View，能传弱引用就传弱引用。这一条是很能区分"读过事故"的回答。
给正在准备面试的你
把函数式接口画成一张四象限图：横轴是"有没有入参"，纵轴是"返回值是什么"。右下角 Consumer（有参无返回，副作用型，如点击回调）、右上角 Function（有参有返回，变换型，如映射）、左下角 Supplier（无参有返回，供给型，如工厂）、左上角 Predicate（有参返回布尔，判定型，如过滤）。 每个象限写一句典型场景，再在图中央标一条横线"输出型 / 判定型"，说明 Stream 的 map 走 Function、filter 走 Predicate、collect 走 Collector。面试中关于 Lambda 的问题都能落回这张图。
再补工程案例与踩坑——应用落点是把项目里散在 UI 层的点击监听统一成 setOnClickListener(this::onItemClick) 方法引用形式，把重复的判定逻辑抽成可复用的 Predicate 常量，并给长生命周期的回调补上弱引用改造，避免捕获 View。
复习时别孤立刷题：Stream 常用操作——Lambda 是 Stream 的输入形式，四个接口对应 Stream 的四个阶段。
划两句重点：函数式接口只有一个抽象方法，四个核心接口覆盖常见场景；Lambda 只能读 effectively final 局部变量，成员变量可直接访问；invokedynamic 首次链接，之后开销与匿名类无差别；Android 低版本要用 desugar 或兼容分支。
下一篇聊 Stream 常用操作：map、filter 与 collect 实战——沿着今天这条主线继续往前走。
如果这篇文章对你有帮助，欢迎点赞、在看、转发三连。你的支持就是这个系列持续更新的动力。
「Android软件开发面试·从入门到精通」连载系列
上一篇：Socket-与-HTTP：网络编程的两层视角
下一篇预告：Stream-常用操作：map、filter-与-collect-实战
有任何问题欢迎在评论区留言交流。
