只有@functionalinterface标注的函数式接口（有且仅一个抽象方法）才能用lambda；常见如runnable、comparator等已标注，自定义接口需显式添加该注解并确保抽象方法唯一。
Java里哪些接口能用Lambda？看@FunctionalInterface就够了
不是所有接口都能写成 x -> x + 1 这种形式，必须是函数式接口——也就是**有且仅有一个抽象方法**的接口。JDK 8 起加了 @FunctionalInterface 注解来标示和校验这个约束。
常见误区是以为只要方法少就能用 Lambda：比如自定义接口里不小心多写了一个默认方法（default）或静态方法，或者继承了父接口导致抽象方法不止一个，编译器就会报错：Multiple non-overriding abstract methods found。
- 必须显式加
@FunctionalInterface注解（不加也能用，但失去编译期检查） -
Runnable、Comparator、Predicate、Function等 JDK 自带接口都已标注，可直接用 - 自己写的接口别漏掉
public abstract声明——即使省略了public，编译器仍按 public 抽象方法算，但 IDE 可能提示不明确
怎么把匿名内部类替换成Lambda？记住三步映射
Lambda 本质是匿名内部类的语法糖，替换时核心是「参数类型 → 方法体 → 返回值」三者对齐，而不是照抄结构。
典型错误是忽略上下文类型推导：比如传给 list.sort(Comparator) 的 Lambda，编译器知道两边都是 (String, String) -> int，所以参数类型可以全省；但单独写 (a, b) -> a.length() - b.length() 时，如果没声明变量类型或没在目标位置，编译器会报 Target type of a lambda conversion must be an interface。
立即学习“Java免费学习笔记（深入）”；
- 参数类型能省则省，但一旦出现类型歧义（比如重载方法），就得补全，例如
(String a, String b) -> a.compareTo(b) - 单个表达式可省
{}和return；多语句必须加{}并显式return - 捕获局部变量时，该变量必须是「事实上的 final」——不能在 Lambda 外再赋值，否则编译报错：
local variables referenced from a lambda expression must be final or effectively final
为什么用了Lambda反而抛NullPointerException？
Lambda 表达式本身不会空指针，但它的执行环境会。最常踩的坑是把 Lambda 当作立即执行的代码块，忽略了它只是被包装进函数式接口实例，真正执行时机由调用方决定。
比如传给 Optional.ifPresent(...) 的 Lambda，如果 Optional 是空的，它根本不会执行；但如果误以为它“已经运行过了”，后续又去访问未初始化的字段，就容易混淆空指针来源。
- 检查 Lambda 内部是否直接调用了可能为 null 的对象方法，例如
str -> str.toLowerCase()中str来源不可靠 - Stream 操作链中，
map或filter里的 Lambda 如果依赖外部状态（如共享List），并发执行时可能引发 NPE 或数据错乱 - 避免在 Lambda 里做耗时或阻塞操作（如 IO、锁等待），尤其在 ForkJoinPool 默认线程池中，容易拖慢整个流处理
Lambda 和方法引用混用时，类型匹配比看起来更严格
写成 System.out::println 很简洁，但它背后要求方法签名必须和目标函数式接口的抽象方法**完全一致**：参数数量、顺序、类型、返回值，一个都不能差。
常见失败场景是泛型擦除后类型不匹配。比如 Function<string integer></string> 期望 String -> Integer，你写 Integer::parseInt 是对的；但换成 Function<object integer></object>，哪怕 Object 实际是字符串，编译器也不认——因为 parseInt 参数类型是 String，不是 Object。
-
::左边如果是类名（非实例），表示静态方法引用；如果是实例名（如list::add），表示绑定实例的方法引用 - 构造方法引用用
ClassName::new，注意重载时需靠上下文区分，否则编译报错：reference to XXX is ambiguous - 数组构造引用（如
int[]::new）只适用于一维数组，且只能接受一个int参数表示长度
函数式接口的抽象方法签名决定了 Lambda 的骨架，而 JVM 对它的实现其实是生成私有静态方法 + 动态调用点，这些底层细节通常不影响使用，但一旦涉及序列化、调试或字节码分析，就很容易卡在「为什么这个 Lambda 看不到源码行号」或者「为什么反序列化失败」上——这时候得回头确认接口是否真被 @FunctionalInterface 标准化，以及是否无意中引入了不可序列化的捕获变量。
