Java MethodHandle 如何拼接可选参数：MethodType、asType 与调用点校验

做一层可配置的订单格式化器时，参数经常不是一次性齐全：租户标识固定，语言和金额单位由请求决定。Java 的 MethodHandle 可以把这类调用拆成“先固定参数、再适配类型、最后精确调用”，但顺序弄错时，错误会落在很难读的 WrongMethodTypeException 上。

先用 MethodHandles.insertArguments 固定真正不变的参数，再让 asType 生成目标 MethodType，调用点使用与句柄完全一致的签名执行 invokeExact。

先把原始调用链固定下来

示例把订单编号、金额和语言交给一个静态方法处理。租户标识由上层路由选定，适合在构建格式化器时提前绑定：

static String formatOrder(String tenant, String orderId, int cents, String locale) {
    return tenant + ":" + orderId + "=" + cents + "(" + locale + ")";
}

MethodHandles.Lookup lookup = MethodHandles.lookup();
MethodHandle formatter = lookup.findStatic(
        FormatterDemo.class,
        "formatOrder",
        MethodType.methodType(String.class, String.class, String.class, int.class, String.class));

此时 formatter.type() 是 (String,String,int,String)String。第一个参数是 tenant，第二个是 orderId，第三个是 cents，第四个是 locale。后面的每次适配都应以这个真实顺序为起点。

用 insertArguments 固定租户参数

insertArguments 的位置从零开始。把 tenant 放在位置 0 后，原句柄的第一个参数被移出，剩余句柄只接收订单编号、金额和语言：

MethodHandle tenantFormatter = MethodHandles.insertArguments(
        formatter, 0, "tenant-a");

System.out.println(tenantFormatter.type());
// (String,int,String)String

这里不要把“固定参数”理解成复制一份字符串再手工拼接。句柄内部仍然保留对 formatOrder 的调用关系，只是把一个输入变成了绑定状态。位置写成 1 会固定 orderId，结果与预期完全不同，而且通常直到运行时才暴露。

用 asType 对齐 MethodType，而不是调整业务顺序

假设调用方把金额作为 Integer 传入，并希望句柄公开成 (String,Integer,String)String。可以显式构造目标 MethodType，让 asType 负责引用类型与基本类型之间允许的适配：

MethodType requested = MethodType.methodType(
        String.class, String.class, Integer.class, String.class);
MethodHandle adapted = tenantFormatter.asType(requested);

String result = (String) adapted.invokeExact(
        "A-17", Integer.valueOf(1299), "zh-CN");
// tenant-a:A-17=1299(zh-CN)

asType 处理的是类型转换，不是位置重排。把 locale 和 cents 交换，仍然会得到一个“看起来像能调用”的签名，但业务值已经错位；如果目标类型根本无法适配，则会直接抛出 WrongMethodTypeException。

invokeExact 的调用点为什么必须写清返回类型

invokeExact 是签名多态方法，调用点的静态描述符必须和句柄类型完全一致。下面的强制转换让返回值描述为 String；如果直接把结果交给 var 或把返回值声明成 Object，调用点签名可能与句柄不一致。

String ok = (String) adapted.invokeExact(
        "A-17", Integer.valueOf(1299), "zh-CN");

try {
    Object wrong = adapted.invokeExact(
            "A-17", Integer.valueOf(1299), "zh-CN");
} catch (WrongMethodTypeException ex) {
    System.out.println(ex.getClass().getSimpleName());
    // WrongMethodTypeException
}

这里的异常不是订单数据错误，也不是 asType 没有生效，而是调用点返回类型不同。排查时先打印 adapted.type()，再对照参数数量、参数类型和返回类型三部分，不要只盯着异常消息。

把参数位置和类型边界写成测试

方法句柄适合封装在工厂里，但工厂必须有小而硬的测试：租户只绑定一次，订单字段顺序不变，金额的适配路径可复现，调用点不接受模糊返回类型。

assertEquals(
        MethodType.methodType(String.class, String.class, Integer.class, String.class),
        adapted.type());
assertEquals(
        "tenant-a:A-17=1299(zh-CN)",
        (String) adapted.invokeExact("A-17", Integer.valueOf(1299), "zh-CN"));
assertThrows(WrongMethodTypeException.class, () ->
        adapted.invokeExact("A-17", Integer.valueOf(1299), "zh-CN"));

最后一个断言在真实测试中应把错误返回类型写成单独的辅助方法或明确的 Object 变量，避免测试源代码本身因签名多态产生编译期推断差异。核心是把失败边界固定下来，而不是依赖某一次调用的异常文本。

常见问题

insertArguments 能否固定中间参数？

可以，位置参数从零开始，固定后该参数从新句柄中移除；位置错一位，后续参数的业务含义就会整体错位。

asType 会自动交换参数顺序吗？

不会。它负责按位置做允许的类型适配，不负责把订单编号、金额和语言重新排列。

为什么 invokeExact 比普通 invoke 更容易报错？

因为它要求调用点描述符与句柄类型完全一致，不做隐式的调用点适配；这正适合把动态调用封装后的契约在测试中锁死。

把动态调用收口成可验证的边界

MethodHandle 的难点不在于 API 数量多，而在于每次组合都会改变可见签名。先查看 formatter.type()，再用 insertArguments 固定 tenant，用 asType 明确 MethodType，最后让 invokeExact 按精确返回类型调用，动态能力就有了清楚的验收边界。