Java 在设计上并不支持基于参数实际类型的运行时多分派（multiple dispatch），其方法重载解析完全在编译期依据参数的静态类型完成。这是语言设计层面经过深思熟虑的主动选择，而非技术限制。
为什么调用 mapper.map(a) 会编译失败？许多开发者的第一反应是“Java 太笨，认不出 a 其实是 A 的实例”。这个说法只对了一半。Java 当然能在运行时识别 a 的实际类型——但**方法重载（overloading）的解析压根儿就不发生在运行时**。编译器的眼中只有变量的声明类型，也就是所谓的静态类型。
在你的示例中，变量 a 的声明类型是 I，而接口 C 里根本没有 map(I) 这个签名。map(A) 和 map(B) 确实存在，但 I 是 A 的超类型，不是子类型。编译器无法安全地将 I 隐式转换成 A 或 B，因此只能给出 "no suitable method found" 的报错。
将这一点与**重写（overriding）**进行对比，差异就显而易见了：重写依赖于接收者的运行时类型，由 JVM 的动态分派（即单分派）完成；而重载的决策权，Java 明确交给了编译器，避免了运行时的犹豫不决。
为什么 Java 选择编译期单分派 + 静态重载解析？
这并非 1995 年语言设计者的疏忽，恰恰相反，这是一次务实的权衡，基于以下几个明确的考量：
优先考虑可预测性
每一个调用点绑定到唯一确定的方法，意味着代码读起来是什么效果，执行起来就是什么效果。这对于理解、调试以及 IDE 的静态分析（如跳转、类型检查）都至关重要。如果同一行代码在不同执行路径下调用的是不同的重载版本，会急剧增加认知负担。您愿意反复猜测“这里的参数到底被当成 Number 还是 Integer 处理”吗？
安全性保障
重载解析存在许多边界情况。例如，一个类同时存在 map(Number) 和 map(Integer) 两个重载，传入 Long 时该如何处理？如果有两个方法同样“合适”，编译器会直接报 ambiguous method call，当场暴露问题。如果把这个决策推到运行时，很可能变成偶发的 ClassCastException 或违反直觉的分支，破坏程序的可靠性。
性能与实现简洁性
编译期解析只需要做一次类型推导，生成固定的 invokeinterface 或 invokevirtual 指令即可。如果改成运行时多分派，每次调用都得进行参数类型的匹配（相当于走 instanceof 链或哈希查找），性能开销不容小觑。而且这套机制与 JVM 现有的虚方法表（vtable）和接口方法表（itable）不兼容，改动起来牵一发而动全身。
避免语义复杂化
引入多分派后，重载与重写的交互会变得极其复杂。例如，子类新增一个更具体的重载方法，是否应该覆盖父类的同名重载？如何定义“更具体”？这些规则稍有不慎就会引发反直觉行为，比如违反里氏替换原则，或出现协变返回类型的冲突。Java 的设计者选择了更简单、更安全的路径。
补充一点：即使把接口声明为sealed interface I permits A, B {}，也**不会改变重载解析的时机**。密封接口确实能约束I的可实例化子类型，有助于 switch 穷举和模式匹配。但a的静态类型仍然是I，编译器不会——也不该——在编译期去“猜测”运行时到底会是A还是B。
替代方案：如何实现类似多分派的效果？
如果业务逻辑确实需要根据参数的实际类型来做路由，可以直接使用 visitor 模式，这是经典的双分派方案：
// 使用访问者模式（显式双分派）
interface I {
R accept(IVisitor visitor);
}
class A implements I {
@Override
public R accept(IVisitor visitor) {
return visitor.visit(this); // this is A → dispatch to visit(A)
}
}
class B implements I { /* 类似 */ }
interface IVisitor {
R visit(A a);
R visit(B b);
}
// 使用时：
String result = new IVisitor() {
@Override public String visit(A a) { return "a"; }
@Override public String visit(B b) { return "b"; }
}.visit((A) a); // 强制转型确保类型安全
或者，利用 Java 17+ 的 switch 模式匹配，写法更安全、更直观：
String result = switch (a) {
case A aInst -> "a";
case B bInst -> "b";
default -> throw new IllegalArgumentException("Unexpected type: " + a.getClass());
};
总结
Java 的重载是编译期静态分派，这是语言为兼顾简洁性、可预测性、安全性和性能而做出的深思熟虑的设计选择。它不是一个缺陷，而是一个明确的权衡结果。开发者需要尊重这个约定：重载用于提供 API 的多态性（不同的参数形式表达统一的语义），而不是用来做运行时类型分发。真正需要根据实际类型来路由行为的地方，请交给面向对象的多态（重写）、模式匹配，或者访问者模式这类显式的分派机制来承担。这样写出的代码，才既清晰又高效。
