静态方法不具备多态性，因其在编译期通过invokestatic指令绑定到引用的声明类型，不依赖运行时对象类型，子类同名方法仅为隐藏而非重写。
父类引用调用 static 方法时，执行的是声明类型（左边）对应类的版本，不是实际对象（右边）所属类的版本——这正是静态方法不具备多态性的核心表现。 它不看 new 了谁，只看变量怎么声明的。很多开发者误以为“重写静态方法”就能实现多态，结果运行时行为与预期严重不符，尤其在工具类封装、配置初始化、回调注册等场景中容易引发隐蔽 bug。
为什么 static 方法调用不走多态？
因为 JVM 在编译期就通过 invokestatic 指令锁定了目标类，完全跳过运行时动态绑定流程：
- 没有虚方法表（vtable）参与，不查继承链，不找子类实现
- 调用目标由引用变量的**声明类型**决定，和 new 后面的构造器无关
- 子类里定义同名 static 方法，本质是“隐藏（hiding）”，不是“重写（override）”
- 父类和子类的 static 方法各自独立存在，互不影响
典型错误写法与真实输出对比
看这段代码：
class Animal { static void sound() { System.out.println("Animal sound"); } }
class Dog extends Animal { static void sound() { System.out.println("Dog wang"); } }
Animal a = new Dog();
a.sound(); // 输出：Animal sound（不是 Dog wang）
即使 a 实际指向 Dog 对象，只要声明类型是 Animal，调用的就是 Animal.sound()。换成 Dog d = new Dog(); d.sound(); 才会输出 Dog wang。
如何避免踩坑？实战建议
- 不要用“父类引用 + static 方法”来模拟多态逻辑；该场景应改用实例方法 + 重写
- 若需按类型差异化行为，优先使用工厂方法、策略模式或依赖注入，而非静态分发
- 静态工具方法命名要体现归属，比如
JsonUtils.toJson()而非Utils.toJson()，避免被误认为可被子类定制 - 单元测试中务必覆盖“父类引用调用子类静态方法”的用例，验证是否真走对了类
和实例方法的关键区别一句话总结
实例方法：编译看左边（能否调用），运行看右边（执行谁的）；
static 方法：编译看左边，运行还是看左边——全程绑定到声明类型。
