JDK 1.8 新特性与函数式编程实战路径

为什么 JDK 1.8 要引入 default 关键字？如果在已有大量实现类的 Collection 接口中新增一个带 default 的方法，原有的实现类会编译报错吗？

我能解释 default 方法的设计动机与影响：1) 1.8前接口只能定义抽象方法，公共逻辑需靠抽象类下沉；2) default 关键字允许在接口内部编写默认实现，方便核心接口向后兼容地引入新功能；3) 新增 default 方法不会导致已有实现类编译报错，它们可直接继承默认逻辑，但如果子类重写则需自己提供实现。

如果一个类实现了两个不同的接口，而这两个接口中又同时包含了完全同名同参数的 default 方法，此时 Java 编译器会怎么处理？会触发什么编译错误？

定义 `public interface IFormula { double calculate(int a); default double sqrt(int a) { return Math.sqrt(a); } }`。匿名内部类实现 `calculate` 后，可直接调用 `formula.sqrt(2)` 求开方，无需在每个实现类里重复编写求平方根逻辑。

为什么 Lambda 表达式必须依赖于函数式接口？如果在一个已标注 `@FunctionalInterface` 的接口中添加一个 `default` 方法，会破坏其函数式接口的特性吗？为什么？

我能复述 Lambda 与函数式接口的关系：1) Lambda 是为了简化单方法接口的匿名内部类实例化而设计的轻量级语法糖；2) 函数式接口必须且只能包含一个抽象方法声明；3) default 方法因为有默认实现所以不是抽象的，在接口中添加任意数量的 default 方法都不会破坏 `@FunctionalInterface` 约束。

在 Lambda 表达式中使用外部的局部变量时，对该变量有什么特殊的修饰符限制？如果尝试在 Lambda 内部修改外部基本类型局部变量的值会引发什么问题？

使用 `Collections.sort(names, (a, b) -> b.compareTo(a))` 替代冗长的 `new Comparator<String>{...}`。定义接口 `@FunctionalInterface public interface IConverter<F,T> { T convert(F from); }`，随后即可使用 `IConverter<String, Integer> converter = (from) -> Integer.valueOf(from);`。

方法引用 `String::valueOf` 和普通 Lambda `s -> String.valueOf(s)` 在底层类型推断上有何异同？如果 Person 类有多个重载构造函数，`Person::new` 是如何确定该调用哪一个的？

我能解释 `::` 引用的分类和推断逻辑：1) `::` 是当 Lambda 体仅执行一个现有方法时的特殊语法糖；2) 包含静态方法引用、实例对象方法引用以及构造器引用；3) 针对构造函数，Java 编译器会根据目标函数式接口

如果条件变化、反例出现或兼容性冲突，这张卡哪里会失效？

补一个贴近原文的类名、方法、配置或调用场景，帮助记住它。