Byte Buddy Maven插件如何处理依赖增强父类的子类转换问题

方案1：官方插件开启增量处理（最简配置） #

如果你是基于官方byte-buddy-maven-plugin扩展的增强逻辑，直接在插件配置中开启incrementalProcessing即可，插件会自动把已经完成增强的类字节码加入后续解析的优先查找路径，子类处理时会自动读到增强后的父类定义：

<plugin>
    <groupId>net.bytebuddy</groupId>
    <artifactId>byte-buddy-maven-plugin</artifactId>
    <version>1.14.12</version>
    <executions>
        <execution>
            <goals>
                <goal>transform</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <!-- 开启增量处理，优先使用已增强的类字节码解析父类 -->
        <incrementalProcessing>true</incrementalProcessing>
        <plugins>
            <plugin>
                <!-- 你的自定义增强插件实现类全限定名 -->
            </plugin>
        </plugins>
    </configuration>
</plugin>

方案2：自定义Maven插件的手动实现 #

如果你是完全自研的Maven插件，没有依赖官方的byte-buddy-maven-plugin，按以下步骤实现：

步骤1：调整类处理顺序，父类优先增强 #

先对所有待增强的类做拓扑排序，继承层级越高的类越先处理，保证父类的增强逻辑先执行完成：

// 对所有待增强类按继承关系排序，父类在前子类在后
List<TypeDescription> sortedTypes = allTargetTypes.stream()
    .sorted((t1, t2) -> {
        if (t1.isAssignableTo(t2)) return -1;
        if (t2.isAssignableTo(t1)) return 1;
        return 0;
    })
    .toList();

步骤2：构造带增强字节码缓存的复合查找器 #

维护一个全局的增强字节码缓存，构造ClassFileLocator时优先从缓存读取，找不到再读取原始类路径的字节码：

// 全局缓存：key为类全限定名，value为增强后的字节码数组
Map<String, byte[]> enhancedClassCache = new ConcurrentHashMap<>();

ClassFileLocator compoundLocator = new ClassFileLocator.Compound(
    // 优先读已增强的字节码缓存
    className -> {
        byte[] bytes = enhancedClassCache.get(className);
        return bytes == null ? ClassFileLocator.Resolution.Illegal.INSTANCE : new ClassFileLocator.Resolution.Explicit(bytes);
    },
    originalClassFileLocator // 你原本读取原始类字节码的查找器
);

// 用复合查找器构造TypePool，绑定到ByteBuddy实例
TypePool typePool = TypePool.Default.of(compoundLocator);
ByteBuddy byteBuddy = new ByteBuddy().with(typePool);

步骤3：增强完成后即时更新缓存 #

每完成一个类的增强，就把生成的字节码写入缓存，后续处理子类时就能读到最新的父类定义：

DynamicType.Unloaded<?> unloadedType = builder.make();
// 写入全局缓存
enhancedClassCache.put(unloadedType.getTypeDescription().getName(), unloadedType.getBytes());
// 后续写入类文件等业务逻辑

兜底兼容：构造函数调用合法性校验 #

如果存在特殊场景的父类构造缺失，可以在定义构造函数前先做合法性判断，避免抛出非法状态异常：

TypeDescription superType = typePool.describe(
    builder.getTypeDescription().getSuperClass().getName()
).resolve();
// 校验父类是否存在包私有无参构造
boolean hasTargetConstructor = superType.getDeclaredMethods().stream()
    .filter(MethodDescription::isConstructor)
    .anyMatch(m -> m.getParameters().isEmpty() 
        && m.getVisibility() == Visibility.PACKAGE_PRIVATE);

if (hasTargetConstructor) {
    builder = builder.defineConstructor(Visibility.PACKAGE_PRIVATE)
        .intercept(SuperMethodCall.INSTANCE);
} else {
    // 自定义兼容逻辑，比如调用父类其他存在的构造函数
}

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