静态/动态类型与静态/动态分派是否存在一一对应关系？

先直接给结论：你列的两个对应关系都是错的。静态/动态类型是类型检查时机的设计选择，静态/动态分派是方法调用目标决策时机的设计选择，二者是完全独立的两个维度，四个组合象限全有广泛的实际应用。

先把几个概念的边界理清楚，避免混淆：

• 动态类型：类型检查发生在运行时，变量没有固定的编译期类型，可以绑定任意类型的值
• 静态类型：类型检查发生在编译期，变量本身有明确的编译期类型约束
• 静态分派：调用哪个方法的决策在编译期（或JIT编译期）就确定，运行时直接跳转到对应代码地址执行
• 动态分派：调用哪个方法的决策需要推迟到运行时，根据参与调用的值的实际类型查表确定

静态类型搭配动态分派是面向对象语言的标准设计 #

你觉得这个组合不合理，核心是混淆了「变量的声明类型」和「变量引用的实际对象的运行时类型」。
所有主流静态面向对象语言（Java、C++、C#等）全支持这个组合，这也是单动态分派最核心的应用场景。举个最简单的Java例子：

// 变量a的声明类型是静态的Animal，编译期就确定，不会变更
Animal a = new Dog();
// 这里的makeSound()调用就是典型的动态分派
// 编译期只知道a是Animal类型，无法确定它指向的实例是Dog/Cat/其他子类
// 必须等到运行时，根据a指向的实际对象类型，决定调用哪个类的makeSound实现
a.makeSound();

这个设计的意义就是实现面向对象的多态：你可以写面向父类接口的通用逻辑，运行时自动适配不同子类的具体实现，不需要在代码里写大量类型判断分支。
这里也刚好对应你在厘清的单动态分派边界：这类静态OO语言的动态分派，只会根据方法接收者（也就是隐含的this/self参数）的运行时类型选择方法，其余参数的类型不参与运行时的分派决策，这也是它和Julia多重分派最核心的差异——Julia的动态分派会把所有位置参数的运行时类型都纳入方法匹配的判断依据。

动态类型搭配静态分派是高性能动态语言的常规优化 #

你觉得这个组合不合理，核心是默认动态类型语言必须对所有调用都走运行时类型查表，但实际工程实现根本不是这样。
最常见的场景就是各类动态语言的JIT优化：不管是JavaScript的V8引擎、Lua的LuaJIT，还是你正在学的Julia，都会在运行时收集代码执行的类型信息。如果某个调用点在多次执行中，传入参数的类型始终固定，JIT就会直接把这个调用的目标静态绑定，甚至直接把方法体内联，跳过运行时的类型检查和分派查表，这就是典型的动态类型场景下的静态分派，是动态语言能跑出接近静态语言性能的核心手段。如果后续执行时传入了其他类型的值，JIT只需要丢弃之前生成的优化代码，回退到动态分派逻辑重新执行即可。
甚至不需要JIT，很多早期的动态类型语言（比如无多态特性的老式BASIC方言）本身就是纯静态分派：所有过程调用的目标在解析源码的时候就固定了，哪怕变量可以在运行时改变类型，遇到类型不匹配的操作直接抛运行时错误就行，根本不需要根据实际类型选择不同的方法实现。

四个组合的常见落地场景汇总 #

• 静态类型+静态分派：C语言普通函数调用、Java的静态方法/final方法/私有方法调用、Rust的静态分发trait调用
• 静态类型+动态分派：Java/C++/C#的虚方法调用、Rust的动态分发trait对象调用
• 动态类型+动态分派：Python/Ruby的普通方法调用、Julia中类型无法被静态推断的泛型函数调用
• 动态类型+静态分派：各动态语言JIT优化后类型确定的调用点、早期无多态的动态BASIC的过程调用

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