javac将Java源码编译为JVM规范的.class字节码，经历语法检查、符号解析、语义分析、字节码生成四阶段，不参与运行时优化；泛型擦除在编译期完成，类型检查在擦除前进行；-source、-target、-bootclasspath参数配置不当易引发ClassFormatError或NoClassDefFoundError。
Java编译器到底在做什么
javac 不是把 Java 代码“翻译成机器码”，而是生成符合 JVM 规范的 .class 文件——一种平台无关的二进制字节码。这个过程不涉及内存分配、线程调度或运行时优化，纯属静态检查与结构转换。
常见误解是认为 javac 会做内联、逃逸分析或泛型擦除后的类型校验；实际上泛型擦除发生在编译期，但类型安全检查（如 List<string></string> 赋值给 List<object></object>）由编译器在擦除前完成，擦除后只保留原始类型。
-
javac默认启用语法检查、符号解析、语义分析、字节码生成四阶段，不可跳过 - 泛型、注解、lambda 表达式等特性均由
javac在编译期处理，而非 JVM 运行时 - 若源码含
assert语句，默认不生成对应字节码指令，需加-source 1.4或更高版本并确保未禁用断言支持
class文件结构里哪些字段真会影响运行
一个 .class 文件本质是紧凑的二进制流，其中 constant_pool、access_flags、attributes 三部分最关键，其余如 minor_version 和 major_version 决定能否被目标 JVM 加载。
比如 major_version = 52 对应 Java 8，JVM 8 可加载，但 JVM 7 会直接抛出 java.lang.UnsupportedClassVersionError；而 SourceFile 属性仅用于调试，删掉也不影响执行。
立即学习“Java免费学习笔记（深入）”；
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
-
Constant pool存放类名、方法签名、字符串字面量等，过大可能触发ConstantPoolTableFullException（极少见，多见于动态生成大量类） -
Synthetic标志位标记编译器自动生成的桥接方法或访问器，JVM 依此跳过某些反射限制 -
StackMapTable属性从 Java 6 开始强制要求（除-XX:+UseSplitVerifier），缺失会导致VerifyError
为什么修改源码后有时不重新编译
javac 默认不做增量编译，所谓“不重编”通常是构建工具（如 Maven、Gradle）或 IDE（如 IntelliJ）的缓存策略导致，而非 javac 自身行为。javac 每次调用都是全新解析，但若输入文件时间戳未变、且输出 .class 已存在且比源文件新，构建工具就跳过调用。
典型陷阱：用 echo "public class A {}" > A.java 覆盖文件，但系统时间精度低于文件系统更新粒度（如 FAT32 的 2 秒），导致 A.class 时间戳 ≥ A.java，构建工具判定无需重编。
- 手动验证是否真跳过：删掉
.class后再编译，看是否生成；或加-verbose参数观察 javac 输出 - Maven 默认使用
maven-compiler-plugin，其useIncrementalCompilation默认 true，但依赖target/classes下的.lastBuildTime文件 - IDE 中关闭 “Build project automatically” 或清空 output 目录，可绕过缓存干扰
javac命令行参数中最容易被误用的三个
-source、-target、-bootclasspath 看似基础，却是线上 ClassFormatError 和 NoClassDefFoundError 的高频源头。它们不控制语法糖是否启用，而是限定语言特性和运行时契约。
例如 javac -source 8 -target 7 是非法组合：Java 8 的 lambda 无法降级为 Java 7 字节码；而 -bootclasspath 若指向低版本 rt.jar，会导致 javac 编译时按旧 API 检查，但运行时却加载新版 JDK 类库，引发 IncompatibleClassChangeError。
-
-source控制语法和 API 可用性（如-source 11允许 var，-source 17允许 sealed 类） -
-target决定生成的major_version，必须 ≥-source对应版本，且不能高于当前javac所属 JDK 版本 -
-bootclasspath应严格匹配目标运行环境的rt.jar（或modules-java.base），现代 JDK 推荐改用--release替代
真正难的不是理解每个阶段做什么，而是当 NoClassDefFoundError 出现时，得快速判断它是类加载失败、字节码版本不匹配，还是 Clinit 静态块抛异常被吞掉——这需要你一眼看出 javap -v 输出里的 major_version 和 Exceptions 表项。
