子类对父类的方法重写：概念、规则与实战避坑
不管你是准备课程设计答辩、应付期末考试，还是刚入行写业务代码，方法重写（Override)都是面向对象绕不过去的坎。我见过太多答辩现场，学生能把“重写是对父类方法的重新实现”背得滚瓜烂熟，可一被问到“子类重写父类方法时访问修饰符能不能比父类更严?”就卡壳。这篇文章就把重写这件事彻底讲透，从概念本质到语法规则，从典型错误到答辩高频追问，一次说清。
1. 方法重写的本质：子类的“自我表达权”
1.1 先搞懂“为什么需要重写”
面向对象编程里，继承的意义不只是代码复用，更核心的是建立一种“is-a”关系：子类是一个特殊的父类。但问题来了——父类定义的方法，并不一定适用于所有子类。
打个比方。父类“动物”定义了“吃东西”这个方法，所有动物都能吃。但“吃东西”的具体方式，猫和狗完全不同：猫细嚼慢咽舔食，狗狼吞虎咽撕咬。如果父类把“吃东西”写成一套通用逻辑，子类硬着头皮继承，就会闹出“所有动物都用同一种方式进食”的笑话。
这时就需要子类把父类的“吃东西”方法拿过来，按自己的行为习惯重新实现——这就是方法重写。一句话概括：子类对继承自父类的某个方法，给出自己的专属实现，方法的签名（方法名和参数列表）保持不变，但方法体内的逻辑由子类说了算。
1.2 重写解决的核心问题
从设计层面看，重写解决的是“通用定义”与“特化行为”之间的矛盾。父类往往只提供通用能力的顶层设计，具体的实现细节留给子类去填充。最典型的例子就是Java中的Object.toString()：所有类都继承了这个方法，可如果你不重写，打印对象就是一堆看不懂的哈希码。重写之后，每个类都能用自己的方式描述对象状态。
同时，重写也是实现“多态”的地基。多态的核心含义是“同一操作作用于不同对象，产生不同行为”。运行时期望调用父类引用指向子类对象时，能执行子类重写过的方法，前置条件就是子类确实重写了该方法。如果没有重写，父类引用调用的永远是父类的实现，那么多态也就无从谈起。
2. 重写的语法规则与细节：答辩提问的重灾区
2.1 方法签名的匹配规则
重写的第一条硬规定：子类重写的方法必须与父类被重写的方法具有相同的方法名和参数列表。这被称为“方法签名的兼容性”。
参数列表相同意味着类型、个数、顺序完全一致。比如父类是void setName(String name)，子类重写时也必须是void setName(String name)。如果子类把参数类型从String改成Object，那就不叫重写，而是定义了一个新的方法——参数列表不同，属于重载（Overload），这是初学者最容易犯的混淆。
方法名更不用多说，大小写敏感，连字母都不能差。我曾见过有人把父类的displayInfo在子类中写成DisplayInfo，编译不报错，IDE也不提示，实际上子类根本没能覆盖父类行为，运行结果和预期完全不符。这类隐蔽问题，只能靠@Override注解来提前拦截。
2.2@Override注解的作用
@Override是Java从JDK 5开始提供的一个注解，专门用来标记“这个方法是重写父类的方法”。它不改变程序逻辑，纯粹是一个编译期的语法校验器。
加了@Override后，如果方法签名和父类不一致，编译器会直接报错。这个特性非常实用——它能在第一时间提醒你“写错了”，而不是等到运行时才发现行为诡异。比如你本来想重写父类的run(int speed)，却不小心写成了run(Integer speed)，没有注解编译器不会报错，你以为重写成功了，实际上是新增了一个方法。
我的建议是：所有打算重写的方法，一律加上@Override。不加它不犯法，但加了它等于多了一道保险。
2.3 访问修饰符的权限变化规则
这是答辩最常被追问的点，也是很多三年经验开发者也容易答错的细节。
重写规则规定：子类重写方法的访问修饰符权限，不能比父类方法的访问权限更严格，可以相同或更开放。
具体来说：如果父类方法定义为public，子类重写时就必须是public；父类方法定义为protected，子类可以是protected或public，但不能是private或默认权限（包私有）；父类方法是默认权限时，子类只能保持默认权限或更开放，不能变为private。
为什么要有这条规则？目的是维持多态的正确性。设想一下：父类对外暴露了public方法，意味着任何外部代码都可以通过父类引用调用这个能力。如果子类重写时把访问权限降为private，那么通过父类引用调用时，按说应该走到子类实现，可private则意味着子类之外不可见——这就会造成逻辑冲突。所以语言设计者干脆用编译规则强制执行权限只能放宽，不能收缩。
2.4 返回值类型的两种情形
返回值的规则分两种情况：基本类型必须完全相同；引用类型可以“协变返回”。
协变返回在Java 5之后被允许。比如父类方法是Animal getAnimal()，子类重写时返回Dog getAnimal()，只要Dog是Animal的子类就行。这提升了重写的灵活性，子类可以用更具体的类型来表达自己的特化行为。
实际项目中协变返回用得不算频繁，但设计框架时很实用。比如一个工厂方法在父类中返回抽象基类，子类重写时返回具体的子类对象，调用方拿到后就能用更丰富的方法，无需额外转型。
2.5 异常声明的变化规则
异常声明规则也有一套严密的限制：子类重写方法声明的受检异常，必须是父类方法声明的同类型异常或其子类，且不能新增父类没有声明的受检异常。
底层逻辑是“能力不能缩水”。父类方法如果声明会抛出IOException，说明调用方已经准备好处理IOException。子类重写时如果改为抛出Exception（更大范围的异常），调用方按父类的声明来处理，接不住子类抛出的新异常，程序就会崩溃。所以编译器禁止这种“扩容”行为。
但注意一点：RuntimeException（非受检异常）不受此限制。子类可以声明抛出任何运行时异常，甚至可以省略所有异常声明，因为运行时异常不要求调用方强制捕获。
2.6 静态方法、私有方法、final方法为什么不能重写
这三类方法是重写规则的例外。
static方法属于类本身，不参与实例的多态分派。子类定义一个同签名的static方法，不叫重写，叫“隐藏”（Hide）。调用的时候取决于引用类型：用父类引用调用，走父类静态方法；用子类引用调用，走子类静态方法。这很容易造成混淆，所以绝不建议在子类中定义与父类同签名的静态方法。
private方法对子类完全不可见，子类无法感知它的存在，自然也就谈不上重写。子类中写一个和父类private方法同签名的方法，那仅仅是一个全新的方法，不会产生覆盖效果。
final方法是父类明确“冻结”的方法，表示实现已经定死，不允许子类改动。这是封装不变行为的手段，也体现了设计意图的传递。
3. 重写、重载与隐藏：三个容易搅浑的概念
3.1 重写和重载的本质区别
答辩现场，“重写和重载的区别”几乎是必问题。虽然两者名字都有个“重”字，但含义截然不同。
表：重写与重载的对照
| 比较项 | 方法重写（Override） | 方法重载（Overload） |
|---|---|---|
| 方法名 | 必须相同 | 必须相同 |
| 参数列表 | 必须相同 | 必须不同（类型、个数、顺序） |
| 所在类 | 发生在父子类之间 | 发生在同一个类中 |
| 方法体 | 重新实现 | 各自独立实现 |
| 返回值 | 基本类型必须相同，引用类型可协变 | 不要求，可以不同 |
| 绑定方式 | 运行时绑定（动态多态） | 编译期绑定（静态多态） |
@Override | 可用且推荐 | 不可用，编译报错 |
记忆口诀很简单：重写看“父子关系”，重载看“参数差异”；重写是纵向的多态，重载是横向的同名方法集。
3.2 重写和隐藏的区别
隐藏主要涉及静态方法，前面提过。子类定义和父类同签名的静态方法，父类的该方法就被“隐藏”了，但二者不是覆盖关系。运行期到底执行哪一个，取决于引用变量的类型，而非实际对象类型：
class Parent { public static void info() { System.out.println("Parent info"); } } class Child extends Parent { public static void info() { System.out.println("Child info"); } } Parent p = new Child(); p.info(); // 输出 Parent info，因为静态方法看引用类型很多开发经验不足的人在这个例子上栽跟头，以为p指向的是Child对象，就会走Child的静态方法。实际输出是“Parent info”，因为静态方法在编译期就绑定了。
3.3 属性为什么不被“重写”
字段（成员变量）不存在重写一说，只有“隐藏”。子类可以定义与父类同名的实例变量，但父类的字段并不会消失，只是被“遮蔽”了。访问哪个字段，由引用类型决定，而不是对象类型，这和静态方法的行为类似。
class Parent { String name = "parent"; } class Child extends Parent { String name = "child"; } Parent p = new Child(); System.out.println(p.name); // 输出 parent建议：永远不要在生产代码里让子类的字段和父类字段重名。这种遮蔽行为极易引发混乱，代码可读性极差，纯粹给自己埋雷。
3.4 构造方法不能被重写
构造方法名字必须与类名完全一致，子类和父类类名不同，自然无法重写父类构造方法。子类的构造方法通过super()隐式或显式地调用父类构造方法，来完成父类部分的初始化。
答辩时如果被问到“构造方法能不能重写”，响亮的回答是“不能”，但紧接着要主动补充“子类构造方法必须通过super()调用父类构造方法完成父类状态初始化”。这个补充能明显拉开回答的深度。
4. 实战代码演示：一个课程设计级别的完整例子
4.1 场景描述与代码结构
用一个电子类专业常见的场景来演示：模拟不同电子设备的充电行为。父类Device定义通用接口，子类Phone和Laptop各自重写充电方法。这样一个例子既贴合电子类答辩的选题气质，又能完整展示重写的各个语法要点。
// 父类：电子设备 class Device { protected int batteryLevel = 0; protected String name; public Device(String name) { this.name = name; } // 通用充电方法，子类需要重写 public void charge() { System.out.println(name + " 正在以默认方式充电"); this.batteryLevel = 50; } // 获取电池信息 public void showBattery() { System.out.println(name + " 当前电量: " + batteryLevel + "%"); } } // 子类：手机 class Phone extends Device { private boolean fastCharging; public Phone(String name, boolean fastCharging) { super(name); this.fastCharging = fastCharging; } @Override public void charge() { super.charge(); // 先调用父类逻辑 if (fastCharging) { System.out.println(name + " 开启快充协议，电量提升至 80%"); this.batteryLevel = 80; } } } // 子类：笔记本电脑 class Laptop extends Device { private int powerWatts; public Laptop(String name, int powerWatts) { super(name); this.powerWatts = powerWatts; } @Override public void charge() { System.out.println(name + " 使用 " + powerWatts + "W 电源适配器充电"); this.batteryLevel = Math.min(100, batteryLevel + 30); } }这段代码里，Phone和Laptop都重写了父类的charge()方法。Phone在重写时调用super.charge()，保留了父类的通用逻辑，再增加自己的快充行为；Laptop则完全抛弃了父类的实现，根据设备规格执行全新逻辑。
4.2 多态联动：父类引用的运行时行为
光看重写本身还不够，关键要看多态联动。写一个测试类：
public class DemoTest { public static void main(String[] args) { Device device1 = new Phone("小明手机", true); Device device2 = new Laptop("程序员电脑", 65); device1.charge(); device1.showBattery(); device2.charge(); device2.showBattery(); } }运行结果：
小明手机 正在以默认方式充电 小明手机 开启快充协议，电量提升至 80% 小明手机 当前电量: 80% 程序员电脑 使用 65W 电源适配器充电 程序员电脑 当前电量: 30%关键在于：device1和device2的声明类型都是父类Device，但调用charge()时，Java运行时会根据实际指向的对象类型，动态找到Phone和Laptop中重写后的方法去执行。这就是动态绑定，也是方法重写最强大的地方——程序在运行期自动选择了正确的那一份实现。
答辩时讲到这一步，可以顺手展示：如果在程序里删掉Phone的charge()重写，打印的结果就会变成父类的默认逻辑，电池会停在50%而不是80%。这一对比能直观说明重写对行为的影响。
4.3 用super关键字调用父类版本
重写并不强制子类完全抛弃父类的逻辑。很多时候，子类需要在父类能力的基础上做扩展，这时可以在子类重写方法的方法体内用super.方法名()来调用父类的被重写版本。
@Override public void charge() { // 先检查是否满足基础条件 if (batteryLevel >= 100) { System.out.println(name + " 电已充满，无需充电"); return; } super.charge(); // 父类通用充电逻辑 // 子类额外逻辑... }这种“先父后子”的模式在真实项目中非常常见。扩展父类行为时，父类的字段、初始化逻辑都需要通过super调用才能保证正确。
有一点要记住：super是直接调用父类的实现，跳过当前类重写的逻辑。从这个角度看，它也是绕过重写的一种手段，但滥用会让代码逻辑变复杂，不到万不得已不建议频繁使用。
4.4 参数绑定与静态类型对重写的影响
再补充一个冷门但答辩容易问到的点：如果父类方法接收的是一个父类参数，子类重写时能不能把参数改成子类类型来“半重写”？
答案是：不能，那不是重写，那是重载。举例子更容易理解：
class Parent { public void print(Device d) { System.out.println("Parent print(Device)"); } } class Child extends Parent { // 这是重载，不是重写！参数类型不同 public void print(Phone p) { System.out.println("Child print(Phone)"); } }如果调用：
Parent p = new Child(); Device d = new Phone("test", false); p.print(d); // 调用的是 Parent 的 print(Device)即使d的实际类型是Phone，方法分派时仍按照编译期的参数类型去匹配，找到的还是父类的print(Device)。因为参数的动态类型不参与方法匹配，方法的分派只考虑方法的签名和实际参数在编译期可见的类型。这个例子能有效说明“重写和重载在分派机制上有什么不同”。
5. 高频踩坑与排查技巧：用血泪经历换来的经验
5.1 常见的“以为重写了，其实没有”案例合集
我帮人排查过太多“方法没生效”的问题，绝大多数都不是bug，而是重写没写好。整理了一个高频错误速查表：
| 症状表现 | 真实原因 | 排查方法 | 解决方案 |
|---|---|---|---|
| 主调方法总走父类逻辑 | 参数类型不匹配，变成了重载 | 检查参数列表是否完全相同 | 加上@Override让编译器校验 |
| 子类方法报了“权限降低”错误 | 访问修饰符权限过严 | 检查public/protected/默认 | 放宽权限，和父类保持一致 |
@Override编译直接报错 | 方法签名和父类不一致 | 对照父类方法签名逐项检查 | 修正签名后重新编译 |
| 静态方法未按预期执行 | 混淆了方法隐藏和重写 | 检查方法是否有static关键字 | 改用实例方法设计 |
父类private方法行为未变 | private方法不可重写 | 检查方法是否为private | 改为protected或public |
| 返回值类型报错 | 协变返回规则不满足 | 检查返回类型是否为父类返回类型的子类 | 返回类型改为相同或子类型 |
其中参数类型不匹配、访问权限收窄、private方法“重写无效”这三大错误在教学代码中占据九成以上。
5.2 重写方法中的异常处理陷阱
有一个陷阱值得单独说：重写方法时对受检异常的处理。
class Parent { public void readData() throws IOException { // ... } } class Child extends Parent { @Override public void readData() throws IOException { // 可以，同类异常 } } class ChildBad extends Parent { @Override public void readData() throws Exception { // 编译错误！Exception 比 IOException 范围更大 } }第二种写法编译直接失败。允许的写法是：声明和父类相同的异常、异常的子类，或者不声明异常。这背后的逻辑仍然是“保证调用方按父类契约处理异常时不会落空”。
实际写代码时，很多资浅开发者喜欢在重写方法里直接throws Exception，觉得省事。这种写法不仅违反重写规范，还在代码审查里是大忌。如果你的父类方法抛的是IOException，子类就应该精确地抛IOException或完全不抛，让异常沿着正确的契约流动。
5.3 构造顺序与重写方法联动的坑
子类构造过程中，父类构造方法先执行，而如果父类构造方法内部调用了被子类重写的方法，就可能产生“初始化未完成就调用重写方法”的隐患：
class Parent { public Parent() { init(); } public void init() { System.out.println("Parent init"); } } class Child extends Parent { private String config = "child_config"; public Child() { super(); // 先调用父类构造 System.out.println("Child constructor"); } @Override public void init() { System.out.println("Child init, config = " + config); } }执行new Child()时，输出会是：
Child init, config = null Child constructor子类字段config还没有完成赋值，因为在Java的对象初始化流程中，父类构造先执行完毕，之后才会轮到子类字段初始化和子类构造方法体。子类的init()被父类构造调用时，config还是默认值null。这就是“泄漏的构造器”问题，也是资深面试官爱挖的坑之一。
规避方案很简单：构造方法中不要调用可重写的方法。如果必须初始化通用逻辑，就把初始化逻辑放到final方法或private方法中封装，避免被子类覆盖。
5.4 重写与equals/hashCode的联动
重写equals()的时候，如果不重写hashCode()，会导致对象放入HashSet或HashMap时行为异常。松散地说，equals相等则hashCode必须相等——这是Java的硬性契约。
实际开发中，按业务主键重写equals时，hashCode也要基于同样的字段计算。比如：
@Override public boolean equals(Object o) { if (this == o) return true; if (!(o instanceof Device)) return false; Device device = (Device) o; return Objects.equals(name, device.name); } @Override public int hashCode() { return Objects.hash(name); }这段代码的有趣之处在于：它用到了重写的能力，反过来又规定了你必须承担的重写义务。很多项目Bug的根源就是只重写了equals，忘掉了hashCode。
6. 答辩场景方法重写版块的高频问题缝合
6.1 电子类答辩中重写考点的高频问法盘点
结合“电子类答辩PPT”的高频场景，这里整理了评委最常问的重写相关问题，并给出答题思路。
第一高频：“方法重写和方法重载有什么区别？”这个问题的完整答法，先给定义，再列区别，最后举一个生活中的例子。比如你可以说：重写是父子类之间，儿子用自己的行为覆盖父亲的行为；重载是同一个类之内，同名方法有不同参数列表，类似“同一个操作入口，不同缴费方式”。
第二高频：“重写有什么限制条件？”答法要条理清晰：方法签名必须相同；访问权限不能更严；异常声明的范围不能扩大；返回类型同类型或协变；static/private/final方法不参与重写。回答时最好配合代码板书写几个反例。
第三高频：“父类引用指向子类对象时，调用的方法是谁的？”答：如果是重写方法，运行时绑定到子类的实现；如果是静态方法，看引用类型。可以现场写两行代码当场验证。
第四高频：“为什么重写不能降低访问权限？”答：为了保证多态调用的一致性，维持父类对外的能力契约。如果父类对外公开的能力，被子类偷偷降级为私有，用户通过父类接口来调用就会失败。
6.2 答辩PPT中方法重写的展示思路
做答辩PPT时，不建议堆满代码和概念定义。评委看的是你是否真正理解了机制。这个版块建议按四段式组织：
第一页放“需求痛点”：一个父类实现不能满足所有子类需求，需要子类自己定义行为。 第二页放“关键差异对比表”：重写与重载的概念对比，突出运行期绑定与编译期绑定。 第三页放“核心代码片段+运行结果截图”：展示重写前后行为变化，以及多态调用的结果。 第四页放“踩坑记录”：例如把重写写成重载导致方法不生效，或者构造方法调用重写方法引发的初始化问题。
这个思路能体现出“即使不看代码，也让听众明白你在讲什么”，而这一点在答辩评分里占比很高。
6.3 被追问“为什么输出是这个结果”时的拆解思路
答辩时评委最喜欢追问“为什么这段代码输出是这个结果”。应对策略是先讲“编译期看哪边、运行期看哪边”，再逐层拆解。
固定的路径是：先确认方法是不是重写；然后判断调用点的引用类型和实际对象类型；静态方法看编译期类型，实例方法看运行期实际类型；若为重写关系，则看实际对象类型所对应类中的方法版本。
例如考察这段代码：
Device d = new Phone("test", true); d.charge();拆解思路：charge()是实例方法，属于重写方法；d的编译期类型是Device，但运行期实际是Phone对象；因此运行期会执行Phone中重写的charge()；Phone重写里调用了super.charge()，所以先输出父类默认充电信息，再输出快充协议内容。
这个拆解路径答出来，评委基本就能认定你是真正理解而非背稿。
7. 重写在设计模式中的综合应用观察
方法重写不只是语法考点，更是诸多设计模式赖以运转的基础机制。模板方法模式就是最直接的例子。
模板方法模式的核心思想是：父类定义算法的骨架，把某些步骤推迟到子类实现。父类里写一个final的模板方法，固定流程顺序，子类通过重写各个步骤方法来注入不同的实现。
再比如策略模式，通过接口或抽象类定义策略方法，具体策略类重写该方法实现不同的算法。这里的重写，是运行时动态切换算法的前提条件。
观察这些设计模式，很容易发现一个规律：重写能力的核心价值在于“扩展点”。父类在设计时，能预判哪些行为是稳定的、哪些行为是易变的，然后把易变的点开放给子类重写。这种设计思路比单纯为了复用代码而继承健康得多。
如果项目实践中能主动用重写来预留扩展点，而不是为了继承而继承，代码质量会有一个质的提升。
8. 重写代码的可读性与工程建议落地
聊完理论，最后落到工程经验上。方法重写在真实项目中被滥用的现象同样非常普遍，这里给出三个可落地的工程建议。
第一，重写方法时务必保持行为的一致性。按里氏替换原则，子类重写父类方法后，凡是父类能用的地方，换成子类都必须照样工作。不要重写后改变方法的原始语义。比如父类的charge()语义是“增加电量”，子类重写后却减少了电量，调用方在不了解子类细节的情况下就会踩坑。
第二，重写方法签名的注释一定要写清楚“为什么重写”。团队协作中，谁也不会看到一个重写方法就能立刻理解设计意图，这时一行注释能省下大量排查时间。注释规范建议这样写：“重写原因：父类默认充电逻辑不支持快充协议，需按设备类型定制充电策略”。
第三，新代码优先考虑组合而非继承。方法重写要求子类在is-a语义下成立。如果两个类只是部分能力相似，不构成严格的父子关系，更合理的方案是组合：持有对方的能力接口，在内部调用，而不是强行继承。这样可以显著减少重写的滥用，也让代码更可维护。
这些建议来自真实项目中的反复调试和代码评审，落到自己的代码里，比背下所有语法规则更有价值。重写是一把锋利的手术刀，用好它是能力，克制地用好它，才是工程素养。
