Java中静态方法无法参与多态，因其采用编译期静态绑定，依据引用类型而非运行时对象实际类型调用，子类同名静态方法仅为隐藏而非重写，故不支持多态行为。
Java中静态方法无法参与多态，这是由其绑定机制决定的——它在编译期就确定调用哪个类的方法，不依赖运行时对象的实际类型。所以即便用父类引用指向子类对象，调用静态方法时仍执行父类版本，子类同名静态方法不会被覆盖（只是隐藏）。这点和实例方法的动态绑定有本质区别。
静态方法不支持重写，只存在“隐藏”
子类定义与父类签名相同的静态方法，并不是重写（override），而是隐藏（hiding）。JVM在编译阶段根据引用类型（左边）决定调用哪个类的静态方法，而非运行时对象的真实类型（右边）。
- 例如：
Animal a = new Dog(); a.staticMethod();调用的是Animal.staticMethod()，哪怕Dog里也定义了同名静态方法 - 若直接写
Dog.staticMethod()，才调用子类的版本——说明调用目标完全取决于代码中出现的类名，而非对象实例 - 编译器会发出警告：“static method should be accessed in a static way”，提醒你别用实例调用静态方法
多态失效的根本原因：绑定发生在编译期
Java 方法调用分两种绑定方式：静态绑定（编译期）和动态绑定（运行期）。静态方法属于前者，而实例方法（含重写后的方法）走后者。
- 静态绑定依据：变量声明类型（即引用类型）
- 动态绑定依据：对象实际类型（即 new 出来的类）
- 因此，
Animal a = new Dog()中，a.eat()（非 static）调用Dog.eat()；但a.create()（static）调用Animal.create()
替代静态方法实现多态行为的常用做法
当需要“按类型不同执行不同逻辑”时，应避免依赖静态方法，转而使用面向对象的设计手段：
立即学习“Java免费学习笔记（深入）”；
- 把逻辑移到实例方法中：将原本静态的工具逻辑封装进对象行为，通过重写实现差异化
- 使用工厂模式：由静态工厂方法返回具体类型的实例，再调用其多态方法
- 借助策略接口 + 依赖注入：定义接口（如
PaymentStrategy），让不同实现类提供各自逻辑，运行时根据上下文选择实现 - 必要时用反射+类名判断：虽不推荐，但在极少数配置驱动场景下，可通过
obj.getClass()获取真实类型，再调用对应静态方法——但这破坏了多态初衷，应谨慎评估
Spring 等框架中尤其要避开 static 方法滥用
在依赖注入环境中，静态方法天然排斥 DI 和 AOP，也无法享受代理、事务、循环依赖处理等特性。
- Service 层方法若声明为 static，就无法注入
@Autowired的 Repository 或其他 Bean - Controller 中 static 方法不能被 Spring 管理，也就无法接收参数、处理请求或参与拦截链
- 接口多实现（如多种支付服务）必须靠实例方法 + 接口注入实现，static 方法会让整个扩展机制瘫痪
