private成员在继承中完全不可见，子类既不能直接访问也不能重写或继承，这是Java封装机制的刚性设计，旨在保障父类内部实现自由变更且不破坏子类稳定性。
父类的private成员在继承中完全不可见，子类既不能直接访问，也不能重写或继承——这不是语法疏漏，而是Java封装机制的刚性设计。
private成员对子类彻底屏蔽
父类中标记为private的字段、方法或构造器，仅限该类内部使用。即使子类与父类同包，甚至显式调用super.，编译器也会报错。
-
private方法不会被子类继承，因此不存在“重写”概念；尝试声明同名方法属于全新定义，与父类无关 -
private字段无法通过子类实例或super引用访问，哪怕子类中存在同名字段，两者也毫无关联 - 子类构造器中不能调用父类
private构造器（除非父类提供public/protected构造器供继承链使用）
为什么不允许访问？核心是封装契约
private不是“暂时隐藏”，而是明确划出类的内部边界。它保障父类能自由修改实现细节而不影响子类——比如重构私有方法逻辑、更换私有字段类型，都不应导致子类编译失败。
- 若允许子类访问
private，等于将内部实现暴露为API的一部分，违背面向对象的封装原则 - 子类意外修改私有状态可能破坏父类不变量（invariant），引发难以追踪的运行时错误
- 所有标准库类（如
String、ArrayList）都依赖这一规则维持稳定行为
需要访问时的合规替代方案
当子类确实需读写父类的私有数据，应通过父类主动提供的受控接口，而非绕过限制。
立即学习“Java免费学习笔记（深入）”；
- 父类提供
protected或public的getter/setter方法，明确授权访问意图 - 将本该共享的成员改为
protected（适用于确属继承体系共有的状态或行为） - 使用组合代替继承：把原父类作为子类的成员变量，通过其公共接口协作
- 避免反射——虽技术上可行，但破坏封装、绕过编译检查、易受JVM安全策略拦截，生产环境禁用
一个典型误用与修正对比
错误写法（编译不通过）：
class BankAccount {
private double balance = 0.0;
}
class SavingsAccount extends BankAccount {
void withdraw(double amount) {
balance -= amount; // ❌ 编译错误：无法访问private字段
}
}正确写法（遵循封装）：
class BankAccount {
private double balance = 0.0;
protected double getBalance() { return balance; }
protected void setBalance(double balance) { this.balance = balance; }
}
class SavingsAccount extends BankAccount {
void withdraw(double amount) {
setBalance(getBalance() - amount); // ✅ 通过受控接口操作
}
} 
