在Java等支持类继承的面向对象语言里，当业务模型存在较深的继承层级时，大量子类往往需要给从父类继承来的实例变量赋予相同或相似的初始值。如果把这些赋值语句分散写在每一个子类的构造函数中，不仅会产生明显的代码重复，还会在后续修改默认值的时候引发漏改风险。构造代码块作为一种特殊的类成员，能够在对象实例化阶段帮我们集中处理这类公共初始化动作。
构造代码块的基础机制与执行顺序
构造代码块是指直接在类体中用一对大括号包裹、不依附于任何方法或构造函数的语句块。它在编译期会被复制到每一个构造函数的最前端，从而保证无论通过哪个构造函数创建对象，这些语句都会优先执行。更重要的是，在继承体系中，实例化子类时会先完成父类的初始化：父类构造代码块、父类构造函数、子类构造代码块、子类构造函数依次推进。
理解这个顺序对解决变量重复赋值问题非常关键。很多开发者误以为只有在子类显式调用 super() 之后父类逻辑才生效，其实父类构造代码块早在隐式或显式的 super 调用所触发的父类构造流程中就已经跑完了。我们可以利用这一特点，把对所有子类都通用的字段预设放在父类块里。
下面用一个简单示例展示执行次序。父类定义公共计数与名称默认值，子类不再重复赋值：
public class BaseEntity {
protected int status;
protected String traceId;
// 父类构造代码块
{
status = 0;
traceId = "default";
System.out.println("父类构造代码块执行");
}
public BaseEntity() {
System.out.println("父类构造函数执行");
}
}
public class UserEntity extends BaseEntity {
private String username;
// 子类构造代码块
{
username = "guest";
System.out.println("子类构造代码块执行");
}
public UserEntity() {
System.out.println("子类构造函数执行");
}
}
当执行 new UserEntity() 时，控制台依次输出父类构造代码块、父类构造函数、子类构造代码块、子类构造函数。可以看到 status 与 traceId 的赋值完全由父类块完成，子类无需重写，从根本上消除了重复。
对比构造函数与构造代码块在继承中的适用边界
有人会问，既然构造函数也能赋值，为何不直接在父类无参构造函数里写初始化？区别在于：如果父类存在多个构造函数，且子类可能调用不同的 super 变体，那么把公共逻辑放进父类构造函数体才能保证覆盖；但若父类构造函数本身逻辑复杂、或某些字段需要在子类构造块中基于父类块结果再做调整，单纯依赖构造函数会造成耦合。构造代码块相当于一层“总是在前的预备动作”，它和构造函数是互补关系而非替代。
在复杂对象继承体系中，常常出现中间抽象类。例如 AbstractOrder 下分 OnlineOrder 与 OfflineOrder，二者都要给 createTime、version 赋同样初值。若写在各自构造函数，一旦初值规则变化就要改两处。提取到 AbstractOrder 的构造代码块后，所有后代自动继承该行为，且不会干扰子类构造函数中特有的参数校验。
需要注意，构造代码块不能接收参数，因此它只适合无参的、纯粹依赖固定规则或类内其他字段的初始化。如果赋值依赖外部传入的配置，仍应在构造函数中处理，或结合工厂方法。以下示例展示中间类统一初始化与子类特化的分工：
public abstract class AbstractOrder {
protected long createTime;
protected int version;
{
createTime = System.currentTimeMillis();
version = 1;
}
public AbstractOrder() {}
}
public class OnlineOrder extends AbstractOrder {
private String channel;
{
channel = "web";
}
public OnlineOrder(String channel) {
this.channel = channel;
}
}
这里 createTime 与 version 的重复赋值被彻底移除，OnlineOrder 只关注自身渠道字段。若未来引入 OfflineOrder，同样自动获得父类块赋予的初值，无需复制粘贴。
实战中利用构造代码块规避变量重复赋值陷阱
真实项目里，变量重复赋值难点往往来自“默认值分散且隐性”。比如父类定义 timeout=3000，某子类构造函数写了 timeout=3000，半年后另一个子类拷贝了这段代码却改成 timeout=5000，导致行为不一致。将 timeout 的默认设定收拢进父类构造代码块，并声明为 protected 且尽量不对外暴露 setter，能从架构上堵住这种偏差。
另一个实战场景是资源预载。假设继承树中多个子类都需要初始化一个轻量缓存容器，在父类构造代码块中 new 出容器并赋给保护字段，子类直接使用即可。如果某些子类需要不同容量的缓存，可在自身构造块中基于父类已建容器做参数化调整，而不是从头创建，从而避免重复的建立与赋值语句。
我们还可以通过静态代码块与实例构造代码块配合，进一步分层：静态块负责类级别配置（如读取环境变量一次），实例块负责对象级别公共字段。这样在复杂继承下，变量赋值既有类维度的一致性，又有实例维度的统一性。示例如下：
public class DataNode {
protected static int poolSize;
protected String nodeId;
static {
poolSize = 16;
}
{
nodeId = "node-" + System.nanoTime();
}
}
public class LeafNode extends DataNode {
{
// 直接使用父类块已赋的 nodeId 前缀，仅补充类型标记
nodeId = nodeId + "-leaf";
}
}
通过上述方式，原本需要在每个叶子节点构造函数里写的 nodeId 前缀生成逻辑被父类块接管，子类块只做增强，重复代码清零。构造代码块在复杂对象继承体系里，是消除变量重复赋值、降低维护成本的直接且实用的手段。