java代码块执行顺序为：父类静态代码块→子类静态代码块→父类实例代码块→父类构造方法→子类实例代码块→子类构造方法；静态优先于实例、父类优先于子类、代码块在对应构造方法前执行。
Java 中代码块执行顺序在插件系统中不是“炫技点”，而是决定插件加载可靠性、初始化安全性和资源隔离性的底层逻辑。用错时机，轻则配置未生效、服务空指针，重则类加载死锁、插件间污染。
静态代码块：插件元信息注册的黄金窗口
插件系统常需在类加载阶段就向主程序注册自身能力（如扩展点 ID、支持协议、版本号），此时必须依赖静态代码块——它在插件类首次被引用时自动触发，且仅一次，不依赖任何实例。
- 适合注册全局唯一标识：比如
PluginRegistry.register("auth-provider", AuthPlugin.class) - 禁止在此访问插件实例字段或调用需上下文的方法（如获取配置路径、连接数据库）——这些非静态成员尚未存在
- 多个插件若共用同一静态注册器，要注意执行顺序：JVM 按源码出现顺序执行静态块，避免 A 插件静态块依赖 B 插件已注册但尚未执行的字段
实例代码块：插件对象初始化的统一入口
每个插件实例化（如 new FileStoragePlugin()）时，实例代码块总在构造器之前运行，是做“安全预初始化”的理想位置。
- 可提前校验必需配置项是否缺失，抛出明确异常，避免构造器里一半初始化失败后状态残缺
- 适合加载插件专属资源：读取
plugin.properties、初始化内部缓存容器、绑定监听器 - 能访问
this和所有实例字段，但注意：若构造器参数未赋值完成（如super(...)后才设字段），此时调用依赖这些字段的方法可能出错
局部代码块：插件方法内资源的精准管控
插件对外暴露的方法（如 process(UploadRequest req)）中，局部代码块不参与生命周期管理，但它能帮你规避变量泄漏和内存滞留。
- 处理临时大对象（如解析后的 JSON 树、临时文件流）时，用
{ ... }包裹，让 JVM 尽早回收 - 避免不同逻辑分支重复声明同名变量，提升可读性与维护性
- 它和插件加载顺序无关，但影响单次调用性能——尤其在高频调用的插件接口中，局部块的及时释放直接降低 GC 压力
父子插件继承链中的执行顺序陷阱
当插件采用继承结构（如 BaseNetworkPlugin → HttpPlugin → HttpsPlugin），执行顺序严格遵循：
父类静态块 → 子类静态块 → 父类实例块 → 父类构造器 → 子类实例块 → 子类构造器
- 若父类静态块试图读取子类定义的
static final String PROTOCOL = "https"，而该字段声明在子类静态块之后，就会得到默认值（null或0） - 推荐做法：所有跨层级共享的常量，统一提至顶层抽象插件类中定义并初始化；动态配置则推迟到实例块或构造器中加载
- 调试时可用
System.out.println("HttpPlugin static init")快速定位哪一级初始化卡住或跳过
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
