真正高性能的类型推导必须将类型信息固化在接口契约中，由编译器静态验证，而非依赖运行时反射；泛型接口需通过强类型方法签名、合理泛型绑定和避免宽泛继承来保障编译期类型安全与推导完整性。
直接用反射做类型推导，性能差、类型不安全、调试困难——这不是优化，是妥协。真正高性能的类型推导，必须把类型信息“固化”在接口契约里，让编译器能静态验证，而不是靠运行时 Class.forName() 或 Field.get() 硬扛。
为什么接口比反射更适合作为类型推导载体
反射本质是绕过编译期检查，在运行时查符号表；而接口定义的是行为契约，编译器可全程跟踪实现类的类型参数和方法签名。只要接口设计得当，类型推导就变成编译器自动完成的类型约束求解，而非手动解析字符串或 Method 对象。
- 反射调用
obj.getClass().getMethod("getAge")无法保证方法存在，且返回Object，需强制转型 - 接口方法如
T getAge()在实现类中必须显式提供具体返回类型，编译器可推导出T是int还是Integer - 泛型接口配合
default方法（如 Java 中的Stack<t>.reverse(Supplier<s>)</s></t>）可复用逻辑，同时保留完整类型上下文
如何设计一个支持编译期推导的泛型接口
关键不是“加泛型”，而是让每个方法签名都携带足够类型线索，避免擦除后丢失信息。例如字段访问不能只暴露 Object get(String fieldName)，而应按字段名分拆为强类型 getter。
- 拒绝字符串字段名：不要
get("id")，改用getId()—— 编译器立刻知道返回类型是long或UUID - 用泛型参数绑定实体与视图：如
interface Mapper<s t> { T map(S source); }</s>，调用时mapper.map(user)可推导出T是UserDTO - 对集合操作，明确元素类型：用
<U> List<U> select(Class<U> type)不如直接定义<U> List<U> findAll()，让U由实现类固定（如ProductMapper extends Mapper<Product>）
MapStruct 是怎么做到零反射又保持灵活性的
它不靠运行时扫描注解，而是把映射规则“翻译”成接口的抽象方法，再由注解处理器在编译期生成具体实现类。你写的 @Mapping(target = "name", source = "fullName")，最终变成 target.setName(source.getFullName()) —— 没有 Field.set()，没有 invoke()，只有纯 Java 字节码。
- 所有类型转换逻辑都在生成的
*MapperImpl.java里，IDE 可跳转、可调试、可单步 - 如果源字段类型是
LocalDateTime，目标是String，你必须显式写@Mapper(uses = DateMapper.class)，否则编译失败 —— 类型安全由编译器兜底 - 嵌套映射如
user.getAddress().getCity()会被展开为多层点号调用，不会触发任何反射查找
容易被忽略的陷阱：接口继承链破坏类型推导
当你写 interface BaseMapper<t> { T findById(long id); }</t>，再让 UserMapper extends BaseMapper<User>，看起来没问题。但若中间插一层 interface CrudMapper extends BaseMapper<Object>，整个类型链就断了 —— findById() 返回类型退化为 Object，后续所有推导失效。
- 避免在泛型接口上做“宽泛继承”，尤其是用
Object或?作为类型参数 - 优先用组合：让
UserMapper持有BaseMapper<User>实例，而不是继承它 - Java 14+ 可用
sealed interface限制实现类范围，防止意外类型擦除
最硬的类型推导从来不是靠“猜”，而是靠“声明”。接口就是你和编译器之间的书面协议——写清楚每个方法的输入、输出、约束，剩下的推导工作，交给它就好。别留空子给反射钻。
