抽象类可定义静态方法，但静态方法不参与多态；应分层职责：静态方法提供通用工具逻辑，抽象方法强制子类实现核心行为，final模板方法封装固定流程。
抽象类本身不能“常驻”静态方法——静态方法属于类本身，不参与多态；但你可以通过合理设计，让抽象类既提供高频复用的静态工具方法，又为子类保留清晰、强制的多态拓展边界。关键不是混用，而是分层职责：静态归静态，抽象归抽象。
静态工具方法放抽象类里可行，但需明确边界
Java 允许在抽象类中定义 public static 方法，它们可直接通过类名调用（如 PaymentUtils.formatAmount()），和普通工具类一样高效。这不是“常驻”的技术魔法，而是语法允许的合理组织方式。
- 适合放：与该领域强相关、无需对象状态、不依赖子类实现的通用逻辑（如金额格式化、签名验签辅助、日志前缀生成）
- 不适合放：需要访问子类特有字段、调用抽象方法、或随子类行为变化的逻辑——这类必须交给实例方法或模板方法
- 注意：静态方法无法被重写，也不参与多态。哪怕子类定义同签名静态方法，也只是隐藏（hiding），不是覆盖（overriding）
多态边界靠抽象方法 + final 模板方法来锁定
真正保障多态拓展性的，是抽象类中声明的抽象方法，以及用 final 修饰的模板方法。这两者共同构成“不可绕过”的契约。
-
抽象方法（如
pay(),refund()）强制子类提供具体实现，确保行为多样性 -
final 模板方法（如
executePayment()）封装固定流程（校验→签名→调用抽象pay()→记录），子类只能插入手动环节，不能破坏主干逻辑 - 这样，静态工具方法负责“辅助计算”，抽象方法负责“核心差异”，模板方法负责“流程骨架”——三者各司其职
典型结构示例：支付抽象类
以支付系统为例，一个兼顾工具性和多态性的抽象类可这样组织：
-
public static String formatMoney(double v)—— 工具方法，直接调用，无继承关系 -
public abstract void pay(double money)—— 多态入口，每个子类必须重写 -
public final void process(double amount)—— 模板方法，内含validate()（具体）、sign()（具体）、pay(amount)（抽象） -
protected void validate() { ... }—— 具体方法，子类可选择重写，但非强制
避免常见误用
不要试图让静态方法“参与多态”，也不要让抽象方法去承担工具性职责。混淆会导致：
- 把格式化逻辑写进
pay()里，导致不同支付方式重复造轮子 - 在静态方法里硬编码调用某个子类，破坏开闭原则
- 把本该抽象的方法写成具体实现，再用 if-else 分支判断类型——这是多态的反模式
