java lambda 表达式规范以函数式接口为核心，必须标注@functionalinterface确保单抽象方法约束，方法签名需简洁明确，支持default/static方法但禁止额外abstract方法，lambda写法应兼顾类型推断与可读性。
Java Lambda 表达式本身没有“开发规范”文档，但它的使用必须遵循一套明确、可验证的约束和最佳实践——核心是围绕函数式接口展开的。写得规范，不是靠主观风格，而是让 Lambda 能被编译器识别、类型系统推断准确、团队协作时语义清晰、长期维护时不易出错。
必须标注 @FunctionalInterface
自定义接口若想作为 Lambda 目标，第一道防线就是加注解：
- 加上 @FunctionalInterface 后，编译器会强制检查：接口里是否真只有一个抽象方法
- 误加第二个 abstract 方法（哪怕 private 或 protected）、或继承了另一个含抽象方法的接口，都会立刻报错
- 不加注解也能运行，但失去编译期防护——这是技术债，不是省事
抽象方法签名要干净、直白
Lambda 的写法完全由这个方法决定，所以它得足够“友好”：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 参数类型优先用基础类型（int、String）或泛型（T、Function
），避免套一层自定义包装类 - 返回值类型必须具体，别用 Object 或未约束的 >，否则类型推断常失败
- 方法名不用强求动词化，但要有通用语义：apply、test、get、convert 比 doSomething 更易理解
允许 default / static，但别干扰“单抽象”本质
函数式接口可以有额外成员，前提是它们不破坏核心规则：
- default 方法 和 static 方法 完全允许，它们属于工具逻辑，不参与 Lambda 实现
- 重写 Object 的 equals、toString 等方法，不算抽象方法，不影响函数式接口判定
- 禁止任何第二个 abstract 方法——不管访问修饰符是什么，只要声明为 abstract 就算数
Lambda 写法要匹配上下文，别硬凑简写
语法省略是便利，不是目标；可读性优先于字符数：
- 无参必须写 ()，不能省；单参且类型可推断时，括号可省（如 s -> s.trim()）
- 多参必须带括号（(x, y) -> x + y），类型通常可省（编译器能从接口推）
- 单行表达式可省 {} 和 return；但一旦要写日志、判空、多步处理，就老实用花括号 + return
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
