构造代码块不能替代构造函数，仅适用于所有对象共有的无参无分支初始化；依赖参数、条件判断、资源获取或需子类定制时，必须使用构造函数或显式init方法。
构造代码块不能替代构造函数，它只适合做所有对象共有的、无参的、无分支的初始化动作。一旦初始化逻辑依赖参数、需要条件判断、涉及资源获取或需被子类定制，就必须回到构造函数（或更优的替代方案）。
无法接收参数，导致初始化逻辑僵化
构造代码块没有参数，无法根据构造器传入的不同值做差异化处理。比如一个用户类，有的构造器传入邮箱，有的传入手机号，而状态字段需要按来源设为“EMAIL_VERIFIED”或“PHONE_BOUND”，这种分支逻辑塞进代码块里会出错——它对所有实例一视同仁。
- 错误做法：在代码块里写
status = "PENDING"，然后指望某个构造器再覆盖——但覆盖时机不可控，且易遗漏 - 正确做法：把 status 初始化移到各构造器内部，或统一用
private void init(String source)方法封装，并由构造器显式调用
不支持重载与继承扩展，破坏可维护性
构造代码块对子类完全透明且不可重写。如果父类用了代码块初始化某个字段，子类想跳过、延迟或修改该行为，根本无从下手。而构造函数天然支持重载和 super() 控制，子类可精确干预初始化流程。
- 例如父类用代码块加载默认配置，子类想换配置源——只能复制父类全部构造器逻辑，违背开闭原则
- 换成构造函数 + protected init() 方法，子类就能覆写 init() 或选择不调用 super.init()
隐式执行带来调试与协作风险
代码块在编译期被自动插入每个构造器开头，堆栈里不显示其位置，异常时只报构造器行号，容易误判问题源头。团队协作中，新成员可能忽略它的存在，导致“为什么这个字段总被改掉”的困惑。
立即学习“Java免费学习笔记（深入）”；
- 日志记录、状态标记等副作用操作若放在代码块里，排查时难以定位触发点
- 使用显式 init() 方法或 Builder 模式，调用关系清晰，IDE 可跳转、可打断点、可单元测试
与现代开发工具和模式不兼容
Lombok 的 @Data、@Builder 等注解会绕过构造代码块；Spring 的依赖注入、Jackson 反序列化也通常跳过构造器，更不会执行代码块。这意味着你写的初始化逻辑，在框架场景下可能完全失效。
- 用
@Builder构建对象时，代码块不执行，字段可能为 null 或保持默认值 - JSON 反序列化（如
new ObjectMapper().readValue(json, User.class)）走的是无参构造+setter，代码块虽会执行，但 setter 后续赋值可能覆盖它 - 推荐统一用构造函数参数校验 + 字段 final 声明，或配合
@PostConstruct处理需延迟的初始化
