jdk 11延续模块化架构，标准库拆分为独立.jmod模块，运行时按需加载；安装后非模块化项目仍兼容classpath，但启用模块需用--module-path、配置构建工具并手动引入移除的javafx等组件。

JDK 11 并没有改变安装流程本身，但模块化架构带来的结构性变化，直接影响了安装后的使用方式、依赖管理与项目构建逻辑。这种变化不是“装不上”，而是“装上了之后怎么用不一样了”。

模块化让 JDK 自身结构更清晰

从 JDK 9 开始，标准库不再打包成一个巨大的 rt.jar，而是拆分为几十个独立的模块（如 java.base、java.sql、java.desktop），以 .jmod 格式存放在 $JAVA_HOME/jmods/ 目录下。JDK 11 延续并稳定了这一设计。

• 每个模块自带明确的依赖声明（通过 module-info.class）
• java.base 是唯一无依赖的“根模块”，所有其他模块都直接或间接依赖它
• 运行时不再默认加载全部类，而是按需解析模块，启动更快、内存占用更低

安装后对开发方式的实际影响

安装 JDK 11 或更高版本后，传统“把所有 jar 往 classpath 一扔就跑”的做法依然可用，但模块化带来了新的约束和优化路径：

Codex Auth Cleaner

一款AI工具，主要用于Monitor and clean up invalid Codex authentication files in CPA. Check quota status, disable files returning 401 errors, and perform dual verification before deletion.，适合需要提升相关任务效率的用户。

下载

• 如果项目显式声明为模块（含 module-info.java），编译和运行必须用 --module-path 而非 -cp，否则会报错“module not found”
• 第三方库若未模块化（绝大多数仍是 jar 包），会被自动归入“未命名模块”，其包可被任意模块读取，但无法被其他模块 exports 控制访问
• JavaFX、JavaEE 等原属 JDK 的组件在 JDK 11 中被彻底移除，安装包里根本不存在——不是“隐藏了”，是物理删除。需要用时必须单独引入对应库（如 OpenJFX、Jakarta EE）

构建工具需适配模块路径

Maven 和 Gradle 在 JDK 11+ 下仍能正常构建非模块化项目，但若启用模块化，配置需调整：

• Maven：需设置 <fork>true</fork> 并在 maven-compiler-plugin 中指定 <modules></modules> 参数；测试阶段可能需额外传入 --add-modules
• Gradle：需启用 java-library 插件，并在 sourceSets.main.java.moduleInfo 中定义模块描述
• IDE（如 IntelliJ IDEA）会自动识别 module-info.java 并切换为模块模式，但需确认 Project SDK 设置为 JDK 11+，且模块依赖关系在 Project Structure 中正确映射

兼容性策略：非模块化项目照常运行

JDK 11 的模块系统是“可选增强”，不是强制升级门槛：

• 不写 module-info.java 的老项目，完全不受影响，仍走传统 classpath 加载机制
• JVM 启动时自动将 classpath 上的 jar 视为“自动模块”（Automatic Module），模块名通常来自 jar 文件名
• 只有当你主动想利用封装性、显式依赖控制或减小运行时镜像（如 jlink 构建定制 JRE）时，才需要深入模块系统