@functionalinterface 注解仅存在于 jdk 8+，jdk 7 及更早版本无法编译含该注解的代码；它仅在编译期校验接口是否为函数式，不影响运行时行为，也不赋予接口功能性。
@FunctionalInterface 注解本身是 JDK 8 引入的，**在 JDK 7 及更早版本中无法编译通过**，因为它根本不存在于那个时期的 Java 标准库中。所以严格来说，它没有“低版本兼容表现”——不是行为不同，而是直接不可用。
注解本身不参与运行时逻辑
该注解的保留策略是 @Retention(RetentionPolicy.RUNTIME)，但它的实际作用仅限于编译期检查：告诉编译器“请验证这个接口是否真的只含一个抽象方法”。一旦编译通过，它对字节码、JVM 运行、类加载均无影响。因此：
- 如果你用 JDK 8+ 编译带
@FunctionalInterface的代码，生成的 class 文件在 JDK 7 上仍可加载和使用（只要没用到 JDK 8+ 的 API） - 但你不能用 JDK 7 的 javac 去编译这个源文件——会报错：“cannot find symbol @FunctionalInterface”
- 注解不会让接口“变成功能性接口”，接口是否函数式，取决于结构，而非注解是否存在
低版本 JDK 中的函数式接口照常可用
像 Runnable、Comparator、Callable 这些接口，在 JDK 1.2–7 时代就已存在，且天然满足“仅一个抽象方法”的条件。它们虽无 @FunctionalInterface 注解，但仍是事实上的函数式接口：
- JDK 7 下可正常实现它们（如 new Runnable() { ... }）
- 只是不能用 lambda 表达式——因为 lambda 是 JDK 8 的语法特性，与接口是否被标注无关
- 也就是说：函数式接口的“功能性”由 JVM 和语言规范共同支撑，注解只是辅助标识
跨版本开发建议
若项目需同时支持 JDK 7 编译和 JDK 8 运行（例如构建多版本兼容库），可采取以下做法：
- 避免在源码中直接写
@FunctionalInterface—— 它不是必需的，去掉后接口逻辑不变 - 用构建工具（如 Maven Profile 或 Gradle toolchain）控制编译 JDK 版本，确保注解只出现在 JDK 8+ 编译流程中
- 若必须统一源码，可借助注解处理器或 Lombok 等方案延迟注入，但通常不值得——函数式接口的价值主要在 JDK 8+ 的 lambda 场景中体现
本质上，@FunctionalInterface 是一个“编译期契约声明”，不是运行时能力开关。它不改变兼容性边界，只提升代码可读性和错误预防能力。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
