理解Java子类重写父类方法时访问权限只能放大不能缩小

在Java继承体系中，有一个必须遵守的核心规则：子类重写父类的方法时，访问权限修饰符只能保持不变或者扩大，绝对不能缩小。这并非简单的编码规范，而是Java语言为保证多态性安全而设定的强制性机制。其核心理念可以概括为：父类对其方法公开了“谁有权调用”的承诺，子类必须严格遵守这份契约，甚至提供更宽松的访问权限，而绝不可私自收紧。

为什么禁止缩小访问权限？多态调用的安全基石

Java允许使用父类类型的引用指向子类对象，例如 Animal a = new Dog();，然后通过 a.sound(); 进行调用。此时，实际执行的是 Dog 类中重写后的方法。然而，编译器在编译阶段仅依据 Animal 类中该方法的声明权限做检查。设想一下，如果 Animal.sound() 声明为 public，而 Dog 类在重写时将其访问权限缩小为 protected，那么外部代码试图通过 Animal 引用调用 sound() 时，将会在编译期直接报错：Cannot reduce the visibility of the inherited method。这不是运行时的异常，而是代码根本无法通过编译。

• 父类声明为 public → 子类重写时必须为 public（若改为 protected、default或private，立即编译报错）
• 父类声明为 protected → 子类可选择 protected 或更宽松的 public，但不能降级为包访问权限（default）或 private
• 父类声明为包访问权限（默认，即无修饰符） → 子类可升级为 protected 或 public，但不能是 private
• 父类声明为 private → 此方法不参与继承，子类中的同名方法属于全新定义，并非重写，因此不受此规则约束

为什么允许扩大访问权限？这是安全的增强与扩展

扩大访问权限不会破坏父类已有的约定，反而使子类方法拥有更强的可访问性，这是一种安全的增强行为。例如，当父类方法为 protected 时，子类将其重写为 public。原本能通过父类引用调用的代码依然有效，同时，包外的代码现在也能通过子类引用直接调用该方法。这完全遵守了面向对象设计中的里氏替换原则，并拓展了方法的能力边界。

• protected → public 是完全合法的操作，在框架中从抽象类到具体实现类的演进中非常常见。
• 包访问权限 → protected 或 public 同样合法，适用于将内部工具方法对继承体系的下游类开放。
• 需要注意的是：public 已经是最高权限，因此它只能保持不变，无法再扩大。

常见误区与初学者易踩的坑

许多问题并非源于代码逻辑错误，而是“权限修饰符使用不当”。例如，IDE在自动生成带有 @Override 注解的方法时，默认添加public修饰符，若手动删除，IDE可能不会立即提示错误；单元测试通常在同一个包内运行，包内调用一切正常，但当应用部署到容器（如Spring、Tomcat）中，通过反射进行跨包调用时，就会引发 IllegalAccessError 错误或方法被静默跳过。

• 接口方法默认是 public abstract 的，实现类在重写时必须显式使用 public 修饰符。
• 对于Servlet、Filter等Java EE规范中的类，即使父类声明中没有重复写出 public，你在重写相关方法时也必须明确写上。
• 不要错误地认为将权限改为protected会“更安全”而主动降级，这会导致编译失败。记住，这是Java语言的强制性规则，而非建议。

规则的深层本质：捍卫里氏替换原则

所有这些规则都服务于一个根本目标：确保像 Animal a = new Dog(); a.sound(); 这样的多态调用永远合法且行为可预测。访问权限的收窄会使得通过父类引用“看不到”子类重写的方法，这等同于单方面撕毁了父类与客户端代码之间的调用契约；而权限的扩大则是在履行原有契约的基础上，提供了额外的访问便利，因此是完全安全的。Java选择在编译期就严格拦截所有违规操作，从而避免了运行时可能发生的崩溃或不可预知的行为，极大地提升了代码的健壮性。