双重分派不是语法糖，而是通过两次动态方法调用使行为选择同时依赖调用者和参数类型；它解决单分派语言中因需手动判断双类型组合而导致的逻辑耦合与重复 instanceof 的问题。
双重分派不是语法糖，而是一种通过两次动态方法调用，让行为选择同时依赖“谁调用”和“传了什么类型参数”的机制。它解决的核心问题是：当操作逻辑既跟被处理对象的类型有关，又跟执行操作的对象（比如访问者）类型有关时，如何避免写一堆 if-else 或 instanceof 来硬编码类型判断。
为什么单分派不够用？
Java、C++、C# 等主流语言只原生支持单分派——也就是只能根据“方法调用者”的实际类型做一次多态选择。比如 shape.draw() 能自动调用 Circle.draw() 还是 Rectangle.draw()，但如果你写 renderer.render(shape)，JVM 只能按 renderer 的类型选方法（如果 renderer 有多个子类），却无法再根据 shape 的具体类型进一步细分——除非你在 render 方法里手动加判断。
这导致两个后果：
- 行为逻辑和数据结构耦合变紧：每次新增一种图形，所有渲染器都要改代码
- 类型判定逻辑分散且易错：不同地方重复写
if (shape instanceof Circle)
双重分派怎么工作？
它把一次“需要两个类型共同决定”的调用，拆成两步走，每步各负责一个维度的动态绑定：
-
第一次分派：由元素对象主导，调用
element.accept(visitor)。这一步靠元素自身的多态性，确保进入的是Circle.accept()还是Rectangle.accept() -
第二次分派：在
accept方法内部，调用visitor.visit(this)。注意这里的this是具体类型（如Circle），JVM 就会匹配到visit(Circle c)而不是visit(Rectangle r)—— 这次靠的是重载 + 运行时实参类型
整个链条下来，最终执行的方法是由 element 类型 + visitor 类型 + visit 方法签名三者共同确定的，真正实现了“双变量驱动”。
它怎么绕过 instanceof？
因为类型信息没有丢给运行时检查，而是“编译进方法签名、运行时由 JVM 自动路由”：
-
accept()方法在每个具体元素类中必须重写，哪怕只是调父类实现，否则第一次分派就断了 -
visit(Circle)和visit(Rectangle)是重载方法，不是重写；它们的形参类型就是类型契约 - 当你写
v.visit(circle)，JVM 不看 circle 是不是 Circle 实例，而是看它声明的静态类型是否匹配，再结合实际类型选最精确重载版本
所以你根本不需要写 if (obj instanceof Circle) —— 类型判定已隐含在调用结构里。
什么时候该用双重分派？
适合那些“操作与两类对象强相关”的场景，典型包括：
- 图形系统中的导出（
XMLExporter.visit(Circle)vsPDFExporter.visit(Circle)） - 碰撞检测（
A.collideWith(B)需要同时知道 A 和 B 的具体物理类型） - AST 节点遍历（不同 visitor 对同一节点做语法检查 / 优化 / 生成代码）
只要发现你反复在同一个方法里判断两个对象的类型组合，就是双重分派的信号。
