流浪小鱼1. 先说结论：子类体内到底看得到看不到父类的私有变量
这个问题的标准答案其实只有一句话：子类不能直接访问父类的私有变量，但可以通过父类提供的公有或受保护方法间接访问。
但我发现很多人对这个答案的理解停留在“背结论”的层面，一碰到具体的代码场景就露馅。比如下面这段代码，你有把握一眼说出输出结果吗？
java复制public class Parent {
private String name = "parent";
public String getName() {
return name;
}
}
public class Child extends Parent {
public void print() {
// 这里的 name 能直接用吗？
// System.out.println(name); // 编译报错
System.out.println(getName()); // 可以
}
}
Child 里直接 println(name) 会编译报错，因为 name 是 Parent 的私有字段，Child 的作用域内不可见。但调用 getName() 没问题，因为 getName() 是 public 方法，子类天然继承。
这背后的机制值得说透。Java 的可见性控制发生在编译期，而不是运行期。编译器在解析 name 这个标识符时，会从当前类开始向上逐层查找字段声明，遇到 private 修饰的字段，只要当前类不是声明它的那个类本身，就直接判定为不可见。换句话说，Child 的字节码里根本不会出现对 name 字段的符号引用，编译阶段就被拦住了。
运行期又是另一回事。子类对象在堆内存中确实包含了父类定义的私有字段——它作为对象头之后实例数据区的一部分存在。只是这个字段对子类代码不可见，对 JVM 来说它就在那里。所以有个很经典的追问：子类对象到底“有没有”父类的私有变量？
答案是有，但子类的代码“看不见、摸不着”。字段的存储是物理存在的，可见性是编译期的语法规则。这两件事经常被混为一谈。
还有一个容易踩坑的细节：如果父类和子类各自声明了一个同名变量，会怎样？
java复制public class Parent {
private int value = 10;
public int getParentValue() {
return value;
}
}
public class Child extends Parent {
private int value = 20;
public int getChildValue() {
return value;
}
}
这叫做变量隐藏（Variable Hiding）。子类的 value 和父类的 value 是两个完全独立的字段，各用各的。Child 内部访问 value 得到的是子类自己的 20，但调用继承来的 getParentValue() 时，方法体是在 Parent 类中定义的，它访问 value 时绑定的是父类的那个字段，所以返回 10。很多初学者在这里想当然地认为“子类变量覆盖了父类变量”，实际上字段不存在多态覆盖，只有方法才有多态覆写，字段只会被隐藏。
理解了这个基础，后面几种访问方式才有讨论的意义。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 正攻法：通过父类公开接口间接读写私有变量
最常规、也是实际项目里用得最多的方案，就是让父类提供 getter/setter 或者其他公开方法，子类通过这些方法访问私有变量。这不仅是“能访问”，更是 Java 封装性的体现。
2.1 getter/setter 的正确设计
看一个实际的例子，比如一个订单类：
java复制public class Order {
private String orderNo;
private BigDecimal amount;
private OrderStatus status;
public String getOrderNo() {
return orderNo;
}
public void setOrderNo(String orderNo) {
this.orderNo = orderNo;
}
public BigDecimal getAmount() {
return amount;
}
public BigDecimal calculatePayableAmount() {
// 在这里做金额校验、优惠计算等逻辑
return amount;
}
}
子类继承 Order 后，虽然不能直接操作 orderNo 字段，但可以调用 getOrderNo() 读取，调用 setOrderNo() 写入。这看起来多了一层调用，实际带来两个关键好处：
第一，字段的读写逻辑统一收口在父类。以后如果要在写入 orderNo 时做格式校验、在读取 amount 时做精度处理，只需要改父类的 getter/setter，所有子类自动生效。如果允许子类直接访问字段，这种统一约束就无从谈起。
第二，子类拿到的不是“裸数据”而是“经过加工的数据”。父类的 getter 里完全可以做额外处理，比如缓存、日志、权限校验。直接访问字段就跳过了这些逻辑，一不小心就埋坑。
2.2 不仅仅是 getter/setter，行为方法更关键
现实中，很多场景不是为了“读取字段”，而是为了让父类执行一段依赖私有状态的逻辑。此时应当调用父类的行为方法，而不是把私有状态暴露出来。
举个例子，一个玩家类：
java复制public class Player {
private int hp;
private int maxHp;
public void takeDamage(int damage) {
if (damage < 0) {
return;
}
hp -= damage;
if (hp < 0) {
hp = 0;
}
System.out.println("受到伤害，当前血量：" + hp);
}
public boolean isAlive() {
return hp > 0;
}
}
战士子类需要实现“受到伤害后有概率格挡”的逻辑，正确的做法不是去读 hp 字段（也读不到），而是覆写 takeDamage 方法，或者调用父类的 takeDamage：
java复制public class Warrior extends Player {
private double blockChance = 0.3;
@Override
public void takeDamage(int damage) {
if (Math.random() < blockChance) {
System.out.println("格挡成功，不受伤");
return;
}
super.takeDamage(damage);
}
}
这里的关键点在于 super.takeDamage(damage)——子类复用父类的逻辑，而父类内部的 hp 字段虽然对子类不可见，但父类的方法在运行时操作的是子类对象实例中真实存在的那个字段，所以状态是正确的。
这个模式在真实项目中非常常见：父类管理核心状态，子类通过覆写钩子方法或调用父类方法来参与逻辑，而不是直接操作私有状态。这也是模板方法模式的基础。
2.3 一个常见的误用场景：toString 和 equals
很多人在覆写 toString() 时想拼上父类的私有字段，发现拼不了，转头就去把字段改成 protected，或者干脆写个 getter 加上去。比如：
java复制public class User {
private Long id;
private String username;
// 省略getter/setter
}
public class AdminUser extends User {
private String role;
@Override
public String toString() {
// 想输出 id 和 username，但访问不到
return "AdminUser{id=" + getId() + ", username='" + getUsername() + "', role='" + role + "'}";
}
}
这种写法本身没问题，但反映出一个设计信号：如果你为了让子类拼字符串就把父类所有字段都改成 protected，说明父类的封装边界没想清楚。更合理的做法是让父类自己实现 toString()，子类只在后面追加自己的字段：
java复制public class User {
// 父类自己负责自己字段的展示
@Override
public String toString() {
return "User{id=" + id + ", username='" + username + "'}";
}
}
public class AdminUser extends User {
@Override
public String toString() {
return super.toString() + ", role='" + role + "'";
}
}
这个细节看起来小，但面试官经常会拿它来考察你有没有真正理解“各人自扫门前雪”的封装思想。
3. 改设计：什么时候该把私有变量升级为 protected
在明确了“什么是正确姿势”之后，下一个问题就是：那什么时候值得把字段从 private 改成 protected？
3.1 protected 的语义边界
protected 修饰的成员，对以下两类代码可见：
- 同包下的所有类
- 不同包下的子类
注意，跨包情况下，子类访问父类的 protected 成员时有个限制：只能通过子类类型引用来访问，不能在子类代码里用父类类型引用去访问。举个例子：
java复制package a;
public class Parent {
protected int count;
}
java复制package b;
import a.Parent;
public class Child extends Parent {
public void ok() {
count = 10; // 通过继承，可以，这里使用的是继承下来的成员
}
public void notOk() {
Parent p = new Parent();
p.count = 10; // 编译错误！不能通过父类实例访问protected成员
// 问：为什么？
}
}
notOk() 里 p.count 访问会报错，因为 Child 的代码跨包，只能访问“自己继承来的”受保护成员，而不能访问“父类对象自己的”受保护成员。这个限制经常被忽略，面试问细一点就容易翻车。
3.2 从 private 到 protected 的合理依据
我在实际项目里的判断标准就三条：
-
确实有多个子类需要直接操作这个字段，而且这些操作逻辑非常简单（赋值、累加），不值得为每个字段都写 getter/setter。此时
protected可以减少样板代码。 -
这个字段属于“子类扩展点”的一部分。比如框架设计中的模板方法模式，父类定义流程，某些状态需要子类在流程中直接修改，声明为
protected比提供一堆方法更直观。 -
团队约定俗成，这个字段不会被外部包随意访问，且设计文档里明确了子类可以持有。
反面情况更多。如果字段会被外部类频繁访问，或者需要严格的校验逻辑（比如状态机流转），那就坚持 private + getter/setter。把字段改成 protected 等于给所有子类开了直接写入口，后续想加约束就难了——你得翻遍所有子类去找谁改了这个字段。
3.3 升级到 protected 之后，字段隐藏又是个坑
字段声明为 protected 后，子类可以直接访问。但当子类自己也声明了同名字段时，坑就来了：
java复制public class Base {
protected int total = 100;
}
public class Derived extends Base {
protected int total = 200;
public void print() {
System.out.println(total); // 200，子类自己的
System.out.println(super.total); // 100，父类的
}
}
如果子类里的 total 是无意中声明的（比如重构时复制粘贴），那 print() 里直接用 total 就悄悄用了子类的字段，父类方法里操作的却是父类的字段，两边数据不一致，查 bug 查半天都发现不了。这种问题在字段多、继承深的时候非常隐蔽，所以我对 protected 字段有一条额外建议：子类里不要再声明同名字段。真要声明，也得清楚自己是在做变量隐藏，不是覆写。
3.4 一个折中点：把 getter/setter 设为 protected
有时候字段本身保持 private，但 getter/setter 声明为 protected，也是一个很好的折中。这样外部类无法访问，只有子类和同包类能用。这在写框架或者被大量继承的基类时很实用：
java复制public abstract class AbstractTask {
private TaskState state = TaskState.CREATED;
protected TaskState getState() {
return state;
}
protected void setState(TaskState state) {
this.state = state;
}
}
外部调用方拿不到状态，只有子类在执行过程中可以修改自己的状态。这既保住了封装性，又给了子类足够的操作空间。
4. 偏门手段：用反射绕过访问控制，以及它的代价
有些场景下——比如写测试、做序列化框架、搞 AOP——你确实需要访问一个对象的私有字段，但该类不是你的代码，你无法修改它，也没有提供 getter。这时候 Java 反射就登场了。
4.1 用反射访问私有字段的标准姿势
java复制import java.lang.reflect.Field;
public class ReflectDemo {
public static void main(String[] args) throws Exception {
Child child = new Child();
Field field = Parent.class.getDeclaredField("name");
field.setAccessible(true);
Object value = field.get(child);
System.out.println(value);
field.set(child, "newName");
}
}
关键点解释一下：
getDeclaredField("name")获取的是Parent类自己声明的字段，不包括继承来的。如果你想拿子类继承到的父类私有字段，也得在Parent.class上调用，而不是Child.class。setAccessible(true)会尝试绕开 Java 语言层面的访问控制检查。这是Java 9模块系统出现之前的老办法，在模块化应用里，如果目标包没有对调用方模块opens，这里会抛InaccessibleObjectException。field.get(child)和field.set(child, value)的child参数必须是该字段声明类的实例，或者其子类实例。
4.2 一个常见的反射坑：static 字段
如果是静态私有字段，get 和 set 的第一个参数传 null 即可：
java复制public class Config {
private static String secretKey = "abc123";
}
// 反射访问
Field field = Config.class.getDeclaredField("secretKey");
field.setAccessible(true);
String value = (String) field.get(null);
field.set(null, "newKey");
这个细节看起来不起眼，但面试时如果让你“不改变类结构的情况下修改私有静态字段”，很多人会卡在 get 的参数不知道该传什么。
4.3 那么用反射访问子类里“不可见”的父类私有字段，是不是好方案？
一句话回答：技术上可行，工程上不推荐。
反射带来的问题很明显：
- 性能开销：反射调用比普通方法调用慢一到两个数量级，在热点路径上使用会导致明显的性能下降。
- 可读性差：维护代码的人看到一堆反射逻辑，很难一眼看出数据从哪来、写到哪去，调试也费劲。
- 模块化限制：JDK 9 之后模块系统默认封装内部实现，反射访问不在
exports/opens列表里的包会直接失败。 - 封装被击穿：private 的初衷就是“我不希望别人碰”，你用反射强行改掉，等于无视了类的设计契约。一旦该类的开发者调整字段名或结构，你的反射代码会在运行时静默失败或抛异常，编译期完全发现不了。
用反射的正确场景，在我看来只有这么几类：单元测试里的 Mock 注入（比如给对象塞一个假的依赖）、ORM / 序列化框架（需要把数据库字段映射到私有属性）、调试工具和诊断程序。业务代码里为了省事去反射别人的私有属性，基本属于拿明天的代码债换今天的五分钟。
4.4 绕开访问控制的更新玩法：MethodHandle 和 VarHandle
除了反射，JDK 还提供了 MethodHandle（方法句柄）和 VarHandle（变量句柄）。VarHandle 在访问字段时同样可以指定访问模式，但它的设计目标主要是高性能的原子操作和内存排序控制，不是给你绕开封装用的。
java复制import java.lang.invoke.MethodHandles;
import java.lang.invoke.VarHandle;
public class VarHandleDemo {
private String name = "demo";
public static void main(String[] args) throws Exception {
VarHandle handle = MethodHandles.lookup()
.findVarHandle(VarHandleDemo.class, "name", String.class);
VarHandleDemo obj = new VarHandleDemo();
System.out.println(handle.get(obj));
handle.set(obj, "changed");
System.out.println(obj.name);
}
}
本质上和反射一样，都需要 lookup 在能访问目标成员的前提下才能拿到句柄。所以它在注解处理器、框架内部用得比较多，普通业务代码基本用不上。
5. 面试场景还原：这个知识点最容易被追问的坑
这个话题在 Java 面试里出现频率极高，特别是在校招和初中级岗位的面试中。别看只是个“访问修饰符”的小知识点，面试官能顺着它延伸出很多东西。我把常见的问法和对应的思路整理一下。
5.1 典型问答一：子类继承了父类的私有变量吗？
这是最基础也是最容易说错的一个。常见的错误答案有两种：一种说“继承了”，一种说“没继承”。都不准确。
准确的说法是：从 JVM 内存布局看，子类对象包含父类定义的所有字段（包括私有字段），因为子类实例化时要先初始化父类部分；但从 Java 语言的访问控制规则看，子类的代码无法直接访问父类的私有字段，因此对子类代码而言，这些私有字段是不可见的，也就谈不上“继承使用权”。
这个回答把内存和语法两个层面分开，面试官就会觉得你是真的理解而不是背的。
5.2 典型问答二：那子类怎么访问父类的私有变量？
标准答案是：通过父类提供的 public / protected 方法，比如 getter/setter 或者其他业务方法。如果父类没提供，且你不能改父类代码，理论上可以用反射，但生产环境一般不推荐。要强调“正确姿势是依赖父类公开接口”，这是体现你对封装的理解的关键。
5.3 典型问答三：父类的 private 方法和 private 变量一样吗？
不完全一样，但核心逻辑类似。private 方法也不会被继承，子类不能直接调用。但子类可以声明一个同名同参的方法，这不算覆写，因为父类的私有方法对子类不可见，所以这只是“恰好同名”的独立方法。
java复制public class A {
private void hello() {
System.out.println("A");
}
}
public class B extends A {
private void hello() {
System.out.println("B");
}
}
你让 B b = new B() 再调用 b.hello()，调的是 B 自己的；如果有个 public 方法在 A 内部调用 hello()，那调到的还是 A 的私有方法。这个现象很容易和“方法覆写”搞混，关键是记住：private 方法没有覆写语义，只存在“隐藏”效应，而且这个隐藏对父类自身逻辑没有影响。
5.4 典型问答四：把父类的 private 改成 protected 有什么影响？
这个问题考察的是封装意识。改成 protected 后，不同包子类可以直接访问，同包类也能访问，但外部无关类依然不行。从功能角度说，子类不再需要 getter/setter 就能直接用字段；从设计角度说，这会扩大访问范围，增加字段被随意修改的风险，也会让父类和子类之间的耦合更强。面试时如果能顺带提到“字段隐藏”的风险，会加分不少。
5.5 典型问答五：构造器里的私有字段初始化，子类构造时怎么保证？
一个更进阶的追问是：
java复制public class Parent {
private int value;
public Parent() {
initValue();
}
private void initValue() {
value = 42;
}
}
public class Child extends Parent {
public Child() {
super(); // 隐式调用
}
}
这里编译能通过，执行也没问题。value 是私有字段，但 initValue() 是 Parent 自己的方法，它赋值时操作的是当前对象 —— 即使是 Child 实例，它堆内存里的 value 字段也已经被初始化。所以结论是：私有字段的初始化在父类构造器内完成，子类不需要也不能直接参与，但最终对象里确实有该字段。
如果 initValue() 是 public 且被子类覆写，情况就反转——父类构造器调用的是一个被子类覆写的方法，此时子类字段还没初始化，访问会得到默认零值，这也是著名的“构造器内调用可覆写方法”的坑。别看这个例子简单，它能串起构造顺序、动态绑定、字段初始化时机三个知识点。
5.6 面试答题框架
根据我这些年面试别人和被别人面的经验，遇到“子类访问父类私有变量”这类问题，答题时可以遵循四个步骤：
- 直接回答结论：不能直接访问，可以间接访问。
- 解释原因：Java 访问控制是编译期规则，private 只对声明它的类可见。
- 给出方案：getter/setter 或 protected（以及各自的适用场景）。
- 补充边界：反射/权限修饰符变化带来的风险，或者字段隐藏、动态绑定这些延伸点。
这样答下来，哪怕面试官只问了三个问题，你也能把这块讲得比较立体，给面试官留下“基础扎实、有工程意识”的印象。
6. 实践中的另一个高频坑：Lombok 的 @Getter / @Setter 与继承的配合
既然搜热词里出现了 Lombok 相关的报错，我顺手把这个关联场景也说一下。很多人用 Lombok 给父类加了 @Getter，子类调用 getter 时却发现编译报错，原因通常是对 Lombok 生成方法的继承链路不熟悉。
Lombok 的 @Getter 注解默认生成的是 public 方法，子类是可以继承这些方法的。但有一个常见的坑：父类字段是 private，子类和父类在同一个包时，子类可以调用父类的 getter 吗？
答案是可以。getter 是 public 的，和字段本身可见性无关。反而是 Lombok 的 @Setter 在生成时需要注意：如果父类字段用了 @Setter(AccessLevel.PROTECTED)，子类可以调用 setXxx()，但是外部类不行。这正好对应前面提到的“protected setter”设计思路。
另一个 Lombok 相关的坑是在子类里声明同名同类型字段时，@Getter 会同时生成名字完全一样的方法，覆盖父类的 getter。多数情况下这是无意的，却导致行为诡异。所以，用 Lombok 时更要留意字段隐藏问题——它把样板代码隐藏了，但隐藏不了继承的语义。
7. 一个真实的排查案例：为什么子类调用父类 getter 拿到的是 null
去年帮同事排查过一个线上问题，场景是这样的：有个 BaseEntity 基类，里面定义了 createdTime 字段，用 @Getter 生成 getCreatedTime()，子类 OrderEntity 继承它。在某个接口里，子类对象的 getCreatedTime() 返回 null，但数据库里明明有值。
排查链路是这样的：
- 先看插入数据的地方，发现保存时用的是子类自己的
createTime字段——是的，子类里又声明了一个createTime，用的是LocalDateTime类型，父类里却是Date类型。 - 数据库映射工具（MyBatis 这类）默认按属性名映射，看到子类有
createTime就直接用了子类的字段。 - 查询回来时，子类的
createTime被赋值，父类的createdTime还是 null。 - 结果就是所有人都在调
getCreatedTime()，拿到的是空值。
根因就是变量隐藏 + 命名不一致。如果当时父类把 createdTime 设计成 private 并只提供 getter/setter，子类就不会随意声明同名字段；或者父类直接把这个字段设为 protected，并且明确要求子类必须用同一个字段，也不会出现这种乌龙。
这个案例给我们的启示是：“子类访问父类私有变量”不只是一个面试题，它直接关系到代码在真实业务里会不会出隐性 bug。 许多团队在代码规范里强制“字段一律 private，不允许 protected 字段”，其实就是想用规则规避这类低级错误。但从另一个角度看，合理使用 protected 字段可以提升框架类代码的灵活性，关键还是在团队内部达成共识并配合 code review。
8. 几条可以“抄作业”的实践建议
写到这里，把前面所有内容收敛成几条可以直接落地的建议，你在自己项目里按这个标准来，基本不会踩坑：
- 字段默认私有，能不放 protected 就不放。 让子类通过方法访问状态，而不是直接摸字段，这是封装的本意。
- 只有当你明确要“把部分状态暴露给子类扩展”时，才考虑 protected。 并且把这写在类注释里，防止后续维护者误用。
- 子类中禁止声明和父类同名的字段。 如果确实有需求，优先想清楚命名语义，避免变量隐藏带来的混淆。
- 不要用反射去业务代码里访问私有变量。 只有写框架、工具、测试代码时才值得。
- 面试回答时分开“内存布局”和“访问规则”两个层面，再补一句设计层面的理解。 这个策略适用于所有 Java 访问修饰符相关的问题。
- 慎用 Lombok 在高频继承链上的 getter/setter，尤其是父类子类字段名容易冲突时。 建议写个简单测试验证一下生成的方法行为，别只靠编译器通过就放心。
这些建议背后其实是一个很朴素的思想：权限修饰符不只是编译器的语法开关，更是类与类之间的契约。 你允许谁访问什么、不允许谁访问什么，本质上是在定义这个类的 API 边界。想清楚这层，那些“能不能访问”的面试题就不再是死记硬背，而是顺理成章的事了。