函数式接口的泛型参数仍受类型擦除影响，运行时无法获取具体类型参数；仅当泛型出现在字段、方法签名等静态声明位置时，反射才能获取真实泛型信息。
Java 中函数式接口本身不改变类型擦除规则，它只是带单个抽象方法的接口（如 Function<t r></t>、Consumer<t></t>），其泛型参数依然遵循标准擦除机制：运行时所有 T 都被擦除为 Object 或上界类型。关键在于——函数式接口的类型信息能否在**调用处**或**实现处**被还原，取决于泛型是否被显式保留在字节码签名中。
函数式接口的泛型参数照样被擦除
声明一个函数式接口：
interface Mapper<T> extends Function<String, T> { }
编译后，apply(String) 方法的签名被擦除为 Object apply(String)（若 T 无界）。JVM 不知道你传的是 Mapper<integer></integer> 还是 Mapper<string></string>，二者在运行时共享同一个 Mapper 接口 Class 对象。
这意味着：
立即学习“Java免费学习笔记（深入）”；
- 无法在运行时通过
mapper.getClass().getTypeParameters()得到具体T - lambda 表达式或方法引用创建的实例，其泛型实参不会自动注入到对象内部
- 直接调用
mapper.apply("123")返回的是Object，强制转换由编译器在调用点插入（如(Integer) mapper.apply("123")）
类型信息能保留的唯一场景：接口被作为字段/参数/返回值声明
只有当函数式接口的泛型被**写死在类结构里**（即出现在字段、方法签名、父类/接口继承关系中），反射才可能拿到真实泛型。
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
例如：
class DataProcessor {
private Function<String, Integer> parser; // 字段声明含具体泛型
}
此时可通过反射获取：
-
DataProcessor.class.getDeclaredField("parser").getGenericType()→ 返回ParameterizedType - 再调用
getActualTypeArguments()可得String.class和Integer.class
但注意：这个信息来自字段声明，不是来自 parser 实例本身；如果 parser 是局部变量或 lambda 参数，则无此信息。
实际开发中怎么应对擦除带来的限制
多数框架（如 Stream API、CompletableFuture）不依赖运行时泛型类型做逻辑分支，而是靠编译期推导 + 调用点强转保障安全。若你确实需要在运行时感知泛型类型（比如自定义序列化或类型校验），可采用以下方式：
- 显式传入
Class<R>：如mapToList(source, String.class)，绕过擦除 - 用匿名子类捕获泛型：如
new TypeRef<List<User>>() {}（类似 Jackson 的TypeReference） - 避免在函数式接口实现中做泛型类型判断：不要写
if (t instanceof Class<?>)—— 这永远为 false - 桥接方法干扰需留意：若函数式接口继承自泛型父接口（如
interface MyFunc<T> extends Consumer<T>），重写方法可能生成桥接方法，getDeclaredMethods()可能返回多个同名方法
一句话总结
函数式接口没有特殊豁免权，它的泛型参数照常擦除；你能“拿回来”的类型信息，只存在于它被静态声明的位置（字段、方法签名等），而不是运行时对象实例中。真正起作用的，始终是编译器在调用点插入的类型转换和检查。
