方法重载发生在同一类中，由编译器根据参数列表（个数、类型、顺序）静态绑定；方法重写发生在父子类间，由JVM根据对象实际类型动态绑定，需满足签名一致、访问权限不更严格、异常范围不扩大等约束。
方法重载（Overload）发生在同一个类里
方法重载是编译期行为，只要参数列表不同（参数个数、类型或顺序不同），返回值类型和访问修饰符不影响重载判断。Java 编译器根据调用时传入的实参类型和数量，静态决定调用哪个重载版本。
常见错误：以为 void print(String s) 和 String print(String s) 是重载——其实不是，仅返回值不同不构成重载，编译会报错 duplicate method。
- 参数类型不同：
print(int i)与print(String s)✅ - 参数个数不同：
print()与print(String s)✅ - 参数顺序不同：
print(int i, String s)与print(String s, int i)✅ - 仅返回值不同：
int getId()与String getId()❌ 编译失败 - 仅修饰符不同：
public void run()与private void run()❌ 不构成重载
方法重写（Override）必须满足父子类继承关系
方法重写是运行期行为，子类提供父类已有方法的新实现。JVM 在运行时根据对象实际类型（而非引用类型）决定调用哪个版本，这是多态的基础。
容易被忽略的约束：重写方法不能比父类方法更严格地限制访问权限；不能抛出比父类方法范围更广的检查异常；返回类型必须是父类返回类型的协变类型（如父类返回 Object，子类可返回 String）。
- 方法名、参数列表、返回类型（或协变子类型）必须完全一致
- 子类访问修饰符不能比父类更严格（
protected可重写public，但private方法无法被重写） -
@Override注解强烈建议加上——它能帮你提前发现拼写错误或签名不匹配问题 - 父类
final、static或private方法不能被重写
重载和重写的典型错误现象对比
重载错误通常在编译阶段暴露，比如 cannot resolve method 'xxx(...)' ；而重写错误可能延迟到运行时才显现逻辑偏差，比如本该走子类逻辑却走了父类空实现。
一个高频陷阱：在子类中“看似重写”了父类方法，但因参数类型用了包装类与基本类型混用（如父类是 void handle(int x)，子类写了 void handle(Integer x)），结果变成重载而非重写——此时 @Override 注解会直接让编译失败，暴露问题。
- 重载失败 → 编译报错：
method xxx is already defined或no suitable method found - 重写失败（未加
@Override）→ 静默变成重载，运行时调用不到预期逻辑 - 重写时缩小了异常范围（如父类声明
throws Exception，子类没抛任何异常）✅ 允许 - 重写时扩大了异常范围（如父类没声明异常，子类加了
throws IOException）❌ 编译失败
看字节码能快速验证到底是重载还是重写
用 javap -c 查看编译后字节码，重载的方法在 class 文件里是多个独立方法符号；而重写的方法在子类字节码中会显式标注 ACC_FINAL（如果被 final 修饰）或通过 invokespecial/invokevirtual 指令体现调用逻辑。对调试多态行为很有帮助。
简单验证方式：把子类方法临时删掉，如果父类方法还能被调用且不报错，说明原方法确实是重写；如果删掉后编译就挂了，那大概率是重载中的一环。
class A {
void show() { System.out.println("A"); }
}
class B extends A {
@Override
void show() { System.out.println("B"); } // 这里删掉，main 中 new B().show() 就会输出 "A"
}
真正容易卡住人
process(List) ，子类既想重写它，又想新增 process(String[])。这时候必须明确区分哪些是覆盖、哪些是扩展，否则维护者极易误判调用路径。
