抽象类的核心作用是“定义契约+提供共性”：抽象方法强制子类实现统一行为，具体方法、构造器和初始化块封装可复用逻辑与初始化支持。
抽象类的核心作用不是“全抽象”，而是“定义契约 + 提供共性”。它既划出子类必须实现的底线（抽象方法），又封装可复用的通用逻辑（具体方法），二者分工明确、协同工作。
抽象方法：子类必须补全的“留白”
抽象方法只声明不做实现，像一份待签署的协议条款。比如
Shape
类中声明
，不规定怎么画，只强制所有子类——圆形、矩形、三角形——都得自己提供具体的绘制逻辑。没有这个约束，继承体系就失去统一行为规范。
具体方法：父类已写好的“公共工具”
抽象类完全可以拥有完整实现的方法。例如在
Animal
抽象类里，可以写一个
——所有动物都呼吸，逻辑一致，无需每个子类重复写。这类方法子类能直接继承调用，也可选择重写以定制行为。
构造器和初始化块也属于“具体部分”
抽象类虽不能被
，但它的构造器会被子类构造过程隐式调用，用于初始化共用字段；静态/实例初始化块也能执行预设逻辑。这些都不是空架子，而是支撑子类实例构建的真实基础设施。
为什么不能只要抽象方法？
如果只有抽象方法，那就接近接口，丢失了状态（字段）和可复用行为的能力
如果禁止具体方法，每次添加通用功能（如日志、校验、模板流程）都得在每个子类里复制粘贴
抽象类的价值恰恰在于：一半是“要求”，一半是“支持”——前者保扩展性，后者提开发效率
abstract void draw();void breathe() { System.out.println("正在呼吸"); }new