Java模块化系统与类加载器协同实现插件化：模块声明（exports/requires/uses/provides）定义可见性与依赖，模块路径驱动类加载器分层加载，ModuleLayer确保类型隔离，类加载器在运行时强制执行访问控制。
Java 模块化系统（JPMS）与类加载器不是各自为政，而是分工明确、深度咬合的一体两面：模块系统定义“谁能用谁”，类加载器执行“谁来加载、从哪加载、是否允许访问”。插件化架构正是靠这种协同，实现安全隔离、按需可见、运行时可插拔。
模块声明决定插件边界与可见性
每个插件必须是一个具名模块，核心是 module-info.java 文件：
- exports 明确对外暴露的包——只有导出的接口类，宿主或其他插件才能引用；未导出的实现类天然被隐藏
- requires 声明依赖，JVM 启动时就校验：若所 require 的模块缺失或未导出所需包，直接启动失败，不等到运行时报错
- uses 和 provides 配合 ServiceLoader：插件声明自己提供某服务，宿主通过 ServiceLoader.load() 可自动发现，且类加载器会确保服务接口由宿主模块加载、实现类由插件模块加载，避免 ClassCastException
模块路径驱动类加载器行为分化
传统 classpath 被 --module-path 取代，这直接改变了类加载器的决策逻辑：
- 模块路径上的 JAR 若含 module-info.class，即被视为具名模块，由平台或系统类加载器按模块图加载，严格遵循 exports/opens 约束
- 宿主程序作为“基础模块层”，插件模块通过 ModuleLayer.defineModulesWithOneLoader() 动态挂载到新层，每个层拥有独立的类加载器实例，形成天然的命名空间隔离
- 插件 A 和插件 B 即使都含
com.example.PluginService，只要由不同 ModuleLayer 加载，JVM 就视其为两个完全无关的类型，互不干扰
类加载器承担模块策略的运行时落地
模块声明只是元数据，真正 enforce 访问控制的是类加载器在加载过程中的判断：
立即学习“Java免费学习笔记（深入）”；
- 加载一个类前，类加载器会检查该类所属包是否被当前模块 exports 或 opens；若未开放反射访问却尝试 setAccessible(true)，抛 IllegalAccessError
- 调用
Class.forName("com.plugin.impl.ServiceImpl")时，不仅查类是否存在，更验证调用方模块是否 requires 了该实现所在模块——否则直接失败 - 对于跨模块反射或序列化，可通过 --add-opens 参数让类加载器在初始化阶段动态打开特定包，这是对模块封装的可控松动，而非全局放行
动态插件加载的关键操作链
运行时加载新插件，需四步闭环操作：
- 用 ModuleFinder.of(path) 找到插件模块字节码位置
- 基于当前 ModuleLayer 构建新的 Configuration，加入插件模块依赖关系
- 调用 ModuleLayer.defineModulesWithOneLoader(config, parentClassLoader) 创建新层并绑定专属类加载器
- 从新层中 layer.findModule("plugin.name").get().getClassLoader() 获取加载器，再加载服务实现类并安全转型（前提是接口由宿主模块导出且加载）
