java代码块执行顺序明确为：1.静态块在类首次主动使用时按源码顺序执行一次；2.构造块每次new对象时在父类super()后、构造器体前执行；3.父子类初始化先父后子、先静后动；4.局部块仅限方法内作用域。
Java 中代码块执行顺序在模块化编程中不是直接驱动模块行为的机制，但它深刻影响模块初始化的可靠性、可预测性和封装质量。
静态代码块决定模块级资源的加载时机
模块化系统（如 Java 9+ 的 module-info.java 驱动的模块）仍依赖类加载机制。静态代码块在类首次被加载时执行——这常是模块中工具类、配置管理器或服务注册器的初始化入口。例如一个日志模块的 LoggerFactory 类若用静态块加载默认格式器和输出目标，那么只要该类被任意模块引用（哪怕只是编译期依赖），初始化就会触发。这种“被动触发”特性要求开发者明确区分：哪些初始化必须在模块启动时完成，哪些可延迟到首次使用。
- 多个静态块按源码顺序执行，适合分阶段初始化（如先加载配置、再校验、最后注册监听器）
- 若模块间存在隐式依赖（A 模块类引用 B 模块的静态工具类），B 的静态块会在 A 初始化前执行——这是模块耦合的潜在信号
- 模块描述符无法控制静态块执行顺序，只能靠类路径/模块路径的解析顺序间接影响
实例代码块增强模块内对象的一致性保障
在模块化设计中，组件往往以服务接口形式暴露（如 ServiceLoader 加载的 SPI 实现）。这些实现类的实例代码块，在每次 new 对象或通过反射创建时自动运行，可用于统一设置默认行为、绑定上下文或验证必要字段。它比构造方法更前置，且不随构造函数重载而重复编写。
- 避免在多个构造器中重复写初始化逻辑（比如所有构造路径都要设置
timeout = 3000） - 与模块的“最小权限”原则契合：实例块内声明的变量作用域受限，不会污染外部或跨模块泄漏状态
- 当模块提供不可变对象时，实例块可配合 final 字段完成一次性赋值，确保模块内对象创建即合规
普通代码块提升模块内方法的可维护性
模块不是只靠类和接口组织，方法内部的逻辑分组同样关键。普通代码块（即方法内的 {...}）虽不参与初始化流程，但在模块化方法中承担实际职责：
- 限制临时变量生命周期，防止在长方法中意外复用旧值（尤其在分支多、嵌套深的服务方法里）
- 配合 try-with-resources 或自定义 closeable 资源，形成清晰的“资源申请–使用–释放”小单元，便于模块独立测试和监控
- 让模块内不同业务子流程（如“校验参数”、“调用远程服务”、“组装响应”）在代码层面物理隔离，降低阅读和修改成本
执行顺序意识有助于规避模块启动陷阱
模块启动失败常源于初始化顺序错乱。比如一个模块的配置类依赖另一个模块的加密服务，但加密服务的静态块尚未执行；或某 SPI 实现类的实例块试图读取尚未由模块系统注入的 ModuleLayer 上下文。理解“父类静态 → 子类静态 → 父类实例 → 构造方法”的链条，能提前识别跨模块初始化依赖是否合理。
- 避免在静态块中调用其他模块未保证已加载的类（应改用懒加载或 ServiceLoader 延迟获取）
- 不在实例块中访问模块服务（
ServiceLoader.load(...)）以外的状态，因模块层上下文可能还未就绪 - 将强依赖项检查从静态块后移到首次方法调用中，用双重检查锁等模式提升模块启动健壮性
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
