ASM MethodVisitor.visitMethod无法访问Scala带参方法问题

该问题是多个代码实现问题叠加导致的，核心原因如下：

• 字节码插入顺序违反ASM API规范：你在MyMethodVisitor的visitCode()方法中，先执行了方法调用指令的插入，再调用super.visitCode()。根据ASM的API约定，super.visitCode()是标记方法代码段正式开始的信号，所有字节码指令的插入操作必须在该调用之后执行，提前插入指令属于未定义行为。对于结构简单的无参数Scala方法，ASM碰巧能将指令写入正确的代码段位置；带参数的Scala方法会被Scala编译器额外生成参数签名、局部变量表等元数据，提前写入的指令会被写入元数据区域，不会被JVM识别为可执行指令。
• 插入的方法调用缺少参数压栈逻辑：你调用的JavaAgent.begin(String)是需要传入String类型参数的静态方法，但你在插入INVOKESTATIC指令前，没有任何将String值压入操作数栈的逻辑（比如加载常量字符串的ldc指令），生成的本身就是非法字节码，会触发JVM的字节码验证错误。无参数方法的栈结构简单，碰巧绕过了验证逻辑；带参数方法的栈映射帧结构更复杂，验证阶段直接判定字节码非法，JVM会自动回退使用未插桩的原始字节码，表现为插桩完全不生效。
• ASM版本过低不兼容Scala生成的高版本字节码：你代码中指定的ASM API版本是Opcodes.ASM4，该版本最高仅支持Java 7（Class版本51）的字节码处理，而Scala 2.12及以上版本默认编译生成Java 8+（Class版本52及以上）的字节码，ASM4无法正确解析高版本字节码的栈映射帧、方法属性等内容，带参数的方法包含更多元数据信息，会直接导致ASM生成错误的字节码，触发验证失败。
• 方法匹配逻辑不严谨：你仅通过方法名匹配目标方法，没有匹配方法描述符（方法参数、返回值类型的唯一标识）。Scala编译器会为类自动生成同名的桥接方法、扩展方法等辅助方法，很容易导致匹配逻辑偏差，无法命中你实际要插桩的带参数目标方法。

对应问题点逐一修复即可：

1. 调整visitCode()方法内的执行顺序，先调用super.visitCode()标记代码段开始，再插入自定义字节码指令。
2. 插入静态方法调用前，先通过visitLdcInsn()将需要传入的String参数压入操作数栈，比如要传入方法名可以写visitLdcInsn(methodName)，再执行INVOKESTATIC调用。
3. 升级ASM依赖到最新稳定版（至少ASM9），将所有传入ClassVisitor、MethodVisitor构造函数的Opcodes.ASM4替换为对应高版本的API常量，比如Opcodes.ASM9，保证能正确处理高版本字节码。
4. 方法匹配时同时校验方法名和方法描述符，比如匹配带Int参数、返回值为Unit的move方法时，判断条件改为name.equals("move") && desc.equals("(I)V")，避免误匹配编译器生成的辅助方法。

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