构造代码块不能解决成员变量覆盖冲突，因其不处理变量遮蔽；正确做法是删除子类同名字段，用父类protected字段+构造代码块统一初始化，从源头消除遮蔽。
构造代码块不能直接解决跨类继承中的成员变量“覆盖冲突”，因为它不参与变量遮蔽（variable shadowing）的语义处理。真正需要干预的是设计层面的初始化逻辑组织——而构造代码块可作为辅助手段，在父类和子类中统一、可控地执行初始化动作，避免因重复声明同名变量导致的状态不一致。
先认清问题本质：遮蔽不是初始化问题，是访问歧义
比如 Java 中子类重新声明 public State state;，会完全遮蔽父类的同名字段。此时：
- 父类方法（如
turn_on()）操作的是父类自己的state； - 子类方法操作的是子类自己的
state； -
PowerSwitch中通过sw.state访问的，是父类声明的那个字段（静态类型决定）； - 结果就是：状态实际分裂为两份，逻辑彻底脱节。
构造代码块的合理用法：在父类中集中初始化共享状态
把状态字段保留在父类，并用构造代码块确保每次实例化时都正确初始化，子类无需再声明同名变量：
- 删掉子类中重复的
public State state;声明； - 在父类
Switchable中用构造代码块初始化：
// Switchable.java{ state = State.off; } - 这样所有子类实例共享同一份
state字段，且总被初始化为off； - 子类构造器可省略显式赋值，或仅做额外初始化（如设置型号、功率等）。
若必须保留子类字段（极少数场景），用 protected + 构造代码块协同
当子类确实需要扩展状态（如增加 brightness 或 volume），又想复用父类基础状态时：
- 父类字段改为
protected State state;； - 子类不重声明
state，而是通过构造代码块补充初始化逻辑：
// Lamp.java{ this.brightness = 100; } - 所有状态变更仍走父类字段，子类只追加专属字段；
- 避免任何同名字段声明，从源头消除遮蔽。
对比：错误用法为什么无效
有人试图在子类中写构造代码块来“覆盖”父类字段值，例如：
- 子类仍声明
public State state;； - 再写
{ this.state = State.on; }； - 这只会初始化子类自己的字段，父类字段仍是默认
null或未初始化值； -
PowerSwitch调用sw.state读到的仍是父类字段（可能为null），运行时报NullPointerException。
