如何获取Interceptor中Invocation<T>的实际返回类型以执行差异化逻辑？

核心问题是Java泛型的类型擦除机制：编译后Invocation<T>的proceed()方法返回类型会被擦除为Object，直接通过反射获取方法返回类型自然只能拿到Object。要区分实际的泛型类型，得从Invocation实例的运行时类型信息入手，以下是两种可行方案：

方案一：解析Invocation实例的泛型接口类型 #

当Invocation的实现类是参数化的具体类（或匿名内部类）时，JVM会保留其泛型参数信息，可以通过反射解析这些信息：

public class TargetInterceptor implements Interceptor {
    @Override
    public Object intercept(Invocation<?> invocation) throws Throwable {
        // 遍历Invocation实例实现的所有泛型接口
        for (Type genericInterface : invocation.getClass().getGenericInterfaces()) {
            if (genericInterface instanceof ParameterizedType paramType) {
                // 确认是Invocation接口的参数化类型
                if (paramType.getRawType() == Invocation.class) {
                    // 获取第一个泛型参数（即T的实际类型）
                    Type actualReturnType = paramType.getActualTypeArguments()[0];
                    // 判断是否为Line类型
                    if (actualReturnType == Line.class) {
                        return new CustomLine(); // 返回自定义Line对象
                    }
                }
            }
        }
        // 非Line类型，执行原逻辑
        return invocation.proceed();
    }
}

注意点 #

• 如果Invocation实例是动态代理生成的（比如JUnit内部使用代理实现），getGenericInterfaces()可能无法直接拿到参数化类型，此时需要尝试获取代理的目标对象（可通过Proxy.getInvocationHandler(invocation)拿到处理器，再从中提取目标实例）。

方案二：利用Invocation关联的方法返回类型（JUnit场景适配） #

在JUnit Remote Launcher的场景中，Invocation通常会关联具体的测试方法。可以通过反射获取Invocation内部持有的方法对象，直接读取方法的返回类型：

public class TargetInterceptor implements Interceptor {
    @Override
    public Object intercept(Invocation<?> invocation) throws Throwable {
        // 反射获取Invocation内部的method字段（需根据实际实现调整字段名）
        Field methodField = invocation.getClass().getDeclaredField("method");
        methodField.setAccessible(true);
        Method targetMethod = (Method) methodField.get(invocation);
        
        // 判断方法返回类型是否为Line
        if (Line.class.isAssignableFrom(targetMethod.getReturnType())) {
            return new CustomLine();
        }
        return invocation.proceed();
    }
}

注意点 #

• 这种方式依赖Invocation的内部实现细节，若JUnit后续修改内部字段名，代码会失效，但在无法修改其他代码的限制下，这是一种可行的适配方案。

内容的提问来源于stack exchange，提问作者William Denton