javac 执行完整前端编译流程：词法→语法→语义分析→注解处理→字节码生成；内置注解在语义分析检查，Lombok 等自定义注解处理器在注解处理阶段介入修改 AST 或生成类。
javac 命令到底做了什么
javac 不是简单地把 .java 文件“翻译”成 .class 文件，它执行的是一个完整的前端编译流程：词法分析 → 语法分析 → 语义分析 → 注解处理 → 字节码生成。其中，@Override、@Deprecated 等内置注解会在语义分析阶段被检查；而自定义注解处理器（如 Lombok 的 @Data）则在注解处理阶段介入，可能动态修改 AST 或生成新类。
常见错误现象：javac 报错 “cannot find symbol”，往往不是缺 jar 包，而是当前编译路径未包含依赖的 .class 或源码（比如没加 -cp 或 -sourcepath）；若报 “class file has wrong version”，说明 JDK 版本不匹配（如用 JDK 17 编译但目标运行在 JDK 8 上）。
- 使用
-source和-target（旧版）或--release（推荐）控制源码语法兼容性和字节码版本，例如javac --release 8 Hello.java可确保生成 JDK 8 兼容的 class 文件 - 多个源文件编译时，
javac默认只编译显式列出的文件，不会自动递归查找依赖的.java—— 除非用-sourcepath指明源码根目录 -
-Xlint:all能暴露潜在问题（如未使用的变量、裸类型），但默认关闭；生产环境建议启用
类路径（-cp / -classpath）和模块路径（--module-path）怎么配才不乱
Java 9+ 引入模块系统后，-cp 和 --module-path 各司其职：-cp 用于传统类路径下的非模块化 JAR 或 class 目录；--module-path 用于定位模块化 JAR（含 META-INF/MANIFEST.MF 中的 Automatic-Module-Name 或真正 module-info.class）。
容易踩的坑：java -cp lib/a.jar:lib/b.jar MyApp 中，如果 b.jar 是模块化 JAR 且声明了 requires a，但 a.jar 在 -cp 下而非 --module-path，JVM 会报 Module b not found —— 因为模块路径上的模块无法“看到”类路径上的类（反之亦然，除非用 --add-modules 显式打开）。
立即学习“Java免费学习笔记（深入）”；
- 混合使用时，优先把所有 JAR 放到
--module-path，再用--add-modules ALL-SYSTEM或--add-modules java.xml按需引入系统模块 - 用
java --list-modules查看当前模块图，确认目标模块是否已解析 - IDE（如 IntelliJ）默认用模块路径管理依赖，但 Maven 构建时
maven-compiler-plugin仍默认走类路径，需显式配置true
运行时 ClassLoader 加载 class 文件的真实顺序
JVM 启动后，并不立即加载所有 .class 文件。类加载分三个阶段：加载（Loading）、链接（Linking）、初始化（Initialization），而“加载”本身又由 ClassLoader 按双亲委派模型触发 —— 并非按文件目录顺序，而是按首次主动使用（如 new 实例、调用静态方法、访问静态字段）时的引用链触发。
典型误解：把 MyApp.class 和它依赖的 Utils.class 放同一目录，就认为 JVM 会“一起加载”。实际是 MyApp.main() 执行中首次碰到 Utils.doWork() 时，才委托 AppClassLoader 去加载 Utils.class；若此时 Utils.class 损坏或权限不足，抛出 NoClassDefFoundError（注意不是 ClassNotFoundException，后者发生在 Class.forName() 显式加载失败时）。
-
ClassLoader.getSystemClassLoader()返回的是应用类加载器，它只负责-cp下的路径，不负责--module-path—— 后者由ModuleLayer管理 - 自定义
ClassLoader若重写loadClass()但未调用super.loadClass()，会破坏双亲委派，导致java.lang.String等核心类无法加载 - 用
java -verbose:class MyApp可实时观察每个类何时被哪个 ClassLoader 加载
为什么 javac 编译通过，java 却报 IllegalAccessError
这通常发生在模块边界被绕过时。例如：模块 A 导出 com.a.publicpkg，但内部类 com.a.internal.Helper 被 B 模块通过反射获取并调用其 public 方法 —— javac 编译期只检查语法和可见性声明，不校验模块约束；而 JVM 运行时在链接阶段发现该类未被导出，直接拒绝访问，抛出 IllegalAccessError（不是 IllegalAccessException，后者是反射调用时的检查异常）。
另一个常见场景：使用 sun.misc.Unsafe 或 jdk.internal.ref.Cleaner 等内部 API。JDK 9+ 默认禁止访问，即使加了 --add-opens，若未同时加 --add-exports，编译期无感知，运行时报错。
- 修复方式：对模块间访问，用
requires transitive或exports ... to显式授权；对内部 API，用--add-exports jdk.unsupported/sun.misc=ALL-UNNAMED -
javac -Xdiags:verbose不会提示模块问题，必须靠jdeps --module-path分析依赖图，或用jlink构建最小运行镜像时暴露缺失模块 - Gradle 用户要注意：
compileJava任务默认不启用模块检查，需手动加options.compilerArgs = ['--module-path', ...]
NoClassDefFoundError。 
