构造代码块不是延迟执行器，而是初始化协调者；它在每次对象创建时立即执行，适合字段联动初始化、轻量计算和调用外部延迟方法，但不可用于真正的按需加载。
构造代码块（非静态初始化块）本身不能实现延迟加载——它在每次创建对象时都会执行，且紧随成员变量默认初始化之后、构造函数之前运行，属于“ eager（急切）”阶段。真正支持“按需加载”的是其他机制，比如 lazy（Kotlin）、Supplier + 同步双重检查（Java），或 lateinit（Kotlin，仅限非空引用且不可重置）。但构造代码块可作为统一初始化入口，配合延迟策略完成复杂逻辑的组织与复用。
构造代码块的真实定位：初始化协调者，不是延迟执行器
它适合做三件事：
• 把多个字段的关联初始化逻辑收拢一处，避免重复写在多个构造器里
• 执行轻量级、无副作用的计算（如字符串拼接、数值校验）
• 调用外部工具方法——而真正的延迟加载逻辑应封装在这些被调用的方法中
例如：
- 你不能在构造代码块里直接
new ExpensiveService()并赋值给private final ExpensiveService service——这仍是立即创建 - 但你可以在块里写
this.serviceLoader = ServiceLoader.create();，而serviceLoader是个延迟触发的代理或工厂
配合延迟加载的典型组合模式
把“复杂成员变量”的初始化拆成两层：构造块负责注册/准备，实际加载推迟到首次访问。
-
Java 中用 Supplier + 双重检查：
声明private volatile ExpensiveData data;
在构造代码块中只设this.dataSupplier = () -> loadFromRemote();，不执行get() -
Kotlin 中用 by lazy：
直接声明val config: Config by lazy { loadConfig() }，init 块完全不用管它——by lazy自动保证线程安全和仅执行一次 -
对必须非空又不能用 lazy 的字段（如基本类型或 final 引用）：
用lateinit var配合构造后显式调用初始化方法，该方法可加锁或判断是否已加载
哪些场景误用了构造代码块？
常见错误是把它当“懒加载开关”：
- 在块里写
if (data == null) data = new HeavyObject();—— 这仍是每次 new 都执行，没延迟 - 试图在块里读文件、连数据库、调远程 API —— 不仅违背延迟初衷，还会让构造变慢、失败风险上移至对象创建阶段
- 依赖 this 引用去注册监听或发布事件，结果因子类字段尚未初始化导致 NPE（尤其在父类 init 块中）
实战建议：何时该用、何时绕开
优先考虑以下替代方案：
- 全局共享资源 → 用
private static final+ 静态块预热（注意 IO 禁忌） - 每个实例独有、开销大、使用频次低 → 直接用
Supplier<t></t>或AtomicReference<t></t>封装加载逻辑，首次get()时触发 - 需要保持字段 final 且不可为空 → Kotlin 选
by lazy；Java 可接受非 final，则用 getter + 同步缓存 - 构造代码块只保留“参数校验”“字段联动设置”“日志埋点”等零副作用操作
