函数式接口的核心是恰好有一个未被实现的抽象方法，@FunctionalInterface是编译期校验注解，非必需但强烈建议使用；default、static及重写Object的方法不破坏其性质。
函数式接口的核心是“只有一个抽象方法”，@FunctionalInterface 是用来显式声明并让编译器帮你把关的注解，不是定义函数式接口的必要条件，但强烈建议加上。
定义函数式接口的关键规则
只要接口里**恰好有一个未被实现的抽象方法**（不包括默认方法、静态方法、Object 类中继承来的方法），它就是函数式接口。例如：
-
Runnable：只有void run()一个抽象方法 -
Comparable<t></t>：只有int compareTo(T)一个抽象方法 - 你自己写的接口，哪怕没加注解，只要满足单抽象方法，也能用 Lambda 赋值
@FunctionalInterface 注解的实际作用
它是一个编译期校验工具，不是语法必需项，但加了就能避免低级错误：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 如果接口加了该注解，但实际有 0 个或 2 个及以上抽象方法，编译直接报错
- 它提醒你和团队：这个接口的设计意图就是作为行为参数传递，别随便加新抽象方法
- 生成的 JavaDoc 中会明确标出这是函数式接口，提升可读性
哪些方法不会破坏函数式接口性质
这些成员可以自由添加，不影响“单抽象方法”规则：
立即学习“Java免费学习笔记（深入）”；
-
default 方法：比如
Comparator.reversed()，有具体实现，不算抽象 -
static 方法：比如
Function.identity()，属于工具方法，不需实现 -
重写 Object 的 public 方法：如
boolean equals(Object)，任何类都继承自 Object，已有默认语义
自定义时的实用建议
写自己的函数式接口，重点是语义清晰、用途明确：
- 接口名体现行为，比如
RetryPolicy、Validator<String>，比泛泛的Function<X, Y>更易懂 - 抽象方法命名要直观，比如
boolean test(T t)或T transform(S s) - 搭配 Lambda 使用时，类型推导更准，IDE 支持更好，比如：
RetryPolicy policy = (attempt, ex) -> ex instanceof IOException;
