构造代码块的核心定位是统一处理所有构造路径共有的实例变量初始化任务，执行时机严格在构造方法体之前、字段显式初始化之后（若代码块位于字段声明后则生效），适用于默认赋值、轻量校验与副作用操作。
构造代码块在属性赋值中的核心定位
构造代码块（即非静态代码块）是类中方法外、用 {} 包裹的一段初始化逻辑，它不依赖构造方法声明，却在每次对象创建时自动执行，且严格位于构造方法体之前。它的本质作用是：统一处理所有构造路径共有的初始化任务，尤其是对实例变量的预设值赋予或轻量级校验。
何时该用构造代码块而非构造方法赋值
当出现以下情况时，构造代码块比在多个构造器中重复写相同逻辑更合理：
- 多个构造器都需要为同一组实例变量设置默认值（如
status = "INIT"、createTime = new Date()） - 需在任何构造器执行前完成某些副作用操作（如日志记录、资源预占、简单状态标记）
- 要避免因构造器重载导致的初始化遗漏——把共性逻辑“上提”到代码块，天然保证执行覆盖率
- 变量初始化依赖于尚未被构造器参数覆盖的中间状态（例如先设默认值，再由构造器选择性覆盖）
赋值顺序细节决定行为是否符合预期
Java 对属性的初始化有明确执行链：默认初始化 → 显式初始化 / 构造代码块（谁先声明谁先执行）→ 构造器 → 对象创建后赋值。关键点在于：构造代码块与字段显式赋值语句的相对位置直接影响最终值。
例如：
立即学习“Java免费学习笔记（深入）”；
// 情况一：代码块在字段声明前
{ id = 100; }
private int id = 5;
→ 实际输出 id = 5（显式赋值覆盖了代码块）
// 情况二：代码块在字段声明后
private int id = 5;
{ id = 100; }
→ 实际输出 id = 100（代码块生效）
这是因为编译器会将字段显式初始化语句“提升”到类加载阶段的初始化入口，但其执行时机仍晚于静态内容、早于构造代码块——而构造代码块本身会被编译器“内联”插入到每个构造器开头。因此，**代码块只有在字段声明之后定义，才能真正改变初始值**。
性能影响小，但滥用会引入隐式耦合
构造代码块本身无运行时开销：它被编译进字节码，在构造器调用时作为普通指令序列执行，和手写等效代码性能一致。但它带来的间接成本值得关注：
- 无法被子类重写或跳过，破坏了初始化流程的可扩展性
- 若块内含耗时操作（如 I/O、网络调用、复杂计算），会拖慢所有对象创建路径，且难以按需关闭
- 调试困难：堆栈中不显示代码块名，异常堆栈只指向构造器行号，易误判问题源头
- 与 lombok 等工具不友好，@Data/@Builder 可能绕过代码块逻辑
建议仅用于轻量、确定、无副作用的初始化；重逻辑应下沉至私有初始化方法，并由各构造器显式调用，兼顾清晰性与可控性。
