我每天都会在代码评审里见到不少新手把“编译期报错”和“运行期报错”混为一谈，甚至有人认为只要代码能跑起来，编译期和运行期就是同一回事。今天就把这两个阶段彻底说清楚，顺带把实际开发中关联最深的那几个机制也一并梳理干净。
1. 编译期：javac到底忙了些什么
1.1 从源码到字节码的三步核心加工
很多初学者以为编译就是把.java文件“翻译”成.class文件，这只是结果描述，不是过程描述。javac真正做的是一次完整的信息加工流水线，可以粗略拆成三个阶段。
第一阶段是词法分析和语法分析。词法分析负责把源代码的字符流切分成一个个合法token，比如关键字、标识符、运算符、字面量。语法分析则把这些token组织成一棵抽象语法树（AST），这棵树里承载了完整的代码结构信息，哪些是方法、哪些是字段、哪些是控制流分支，全部都在树里体现。这一步完成后，像括号不匹配、少写分号、方法只有签名没有方法体这类问题就已经暴露出来了。
第二阶段是语义分析。语法结构正确不等于语义正确，语义分析要检查类型匹配、变量是否已声明、方法调用参数个数和类型是否吻合、访问修饰符是否越权。典型场景是当年用“String s = new Date();”这种离谱的赋值，编译器的语义分析阶段会收到明确的类型不兼容信号。也会处理自动拆装箱、强制类型转换的白名单校验、泛型的类型检查与擦除。
第三阶段是字节码生成。语义分析通过后，编译器遍历语法树，按照JVM规范生成对应的字节码指令，最终输出到.class文件。这个阶段还会顺手做一些与语义无关的小优化，比如常量折叠、静态代码合并、去除不可达分支等。到这一步，源码就真正从人能读懂的文本变成了JVM能读懂的结构化指令集。
整个编译过程本质上就是一个静态检查与静态转换的过程。源代码里所有信息在这个阶段被固定下来，那些无法在这个阶段判断或确定的东西，都会被留给运行期去处理。
1.2 编译期能发现错误，也可能放过隐患
编译期检查最典型的就是语法和类型安全。你写错了类型、写错了方法名、漏了返回语句，javac都会直接拒绝生成.class文件。这种“静态类型检查”是Java区别于JavaScript这类动态语言的重要特性，很多低级问题在本地编译阶段就被拦截了，根本轮不到运行期暴露。
但编译期检查有它的边界。它只能做“基于类型声明”的静态检查，无法做“基于实际运行数据”的动态检查。例如代码编译完全通过，运行时数组越界、空指针、除零、类型转换失败，这些都是编译期无法预判的。编译期的检查逻辑有点像体检，只能通过抽血化验来推测你有健康风险，但不能预测你明天是否会感冒发烧。
另外有一个容易被忽略的点：编译期是分模块的。在大型项目里，A模块依赖B模块，如果只重新编译A模块而B模块的jar没更新，那么编译期能看到的B模块类型信息就是旧的。这种“编译期通过但实际运行行为不一致”的场景，通常发生在版本升级、接口变更但没有全量重编的情况下。
1.3 注解处理器：藏在编译期的“编译器插件”
很多人不知道，javac不只是被动翻译代码，它还提供了一套扩展机制，允许第三方代码在编译期间介入，这就是注解处理器。
注解处理器扫描源代码和语法树，读取注解信息，生成新的源文件、字节码或资源文件。最典型的就是某个类库的@Getter/@Setter注解，它在编译期直接为类生成getter/setter方法；还有某个映射工具的@Mapper接口，在编译期根据接口定义生成实现类。这些代码如果让你手写，既枯燥又容易出错，而编译期生成的好处是出错早、零运行期性能损耗、生成的代码跟手写源码混合在一起后还能被编译器继续检查。
这里有一个非常经典的“编译期神器”与“运行期神器”的分水岭问题。注解处理器生成的是编译期的结果，参与的是静态代码，所以它生成的代码在运行期就跟普通源码一模一样，没有反射和动态代理的隐形开销。而基于运行期处理的方案通常通过反射实现，灵活度高但性能有代价，而且很多错误要等到运行时字段名拼错才被发现。选择哪种方案，本质上是“编译期把活干完”还是“运行期动态干”的取舍。
2. 运行期：JVM拿到字节码之后的故事
2.1 类加载：字节码到内存模型的第一个关卡
编译期把源码变成.class文件后，工作就交给了JVM。JVM拿到.class字节码后，第一步就是把这个静态文件加载到内存中，并构建对应的Class对象，这个动作就是类加载。
类加载的完整流程包含五个环节：加载、验证、准备、解析、初始化。加载是找到字节码流并读入内存，验证是检查字节码是否符合JVM规范、有没有恶意或非法的指令序列，准备是为类变量分配内存并设置零值，解析是把常量池里的符号引用替换为直接引用，初始化才是真正执行静态代码块和静态字段赋值。
这里要特别注意解析这个环节，它是编译期和运行期的关键连接点。类在编译期生成字节码时，方法间的调用引用是“符号引用”，类似于一个占位符，只有到运行期解析阶段才被替换成真正的方法入口地址。这就不难理解为什么运行期会抛出NoClassDefFoundError和NoSuchMethodError——源码能编译通过是因为符号引用没有问题，但运行时如果对应类不存在、方法不存在，或者版本不匹配，就会在解析阶段爆雷。
关于类加载还有一个细节值得关注：类不会被“预加载”。JVM按需加载，某个类在代码里出现了，但程序执行路径绕过了它，它就不会被加载。运行期加载失败的错误通常不会在应用启动时就立即暴露，而是等到触发到那条调用路径时才暴露，排查起来经常需要“按路线复现”。
2.2 解释执行与JIT编译：一条渐进的快车道
类加载完成之后，JVM开始真正执行字节码。默认情况下，JVM先用解释器逐条解释字节码并执行。优点是启动快、无等待，缺点是逐条解释效率不高。为了让热代码跑得飞快，JVM引入了即时编译（JIT）。
JIT是运行期内嵌的编译器，它专门盯住那些被反复执行的“热点代码”，把这些字节码直接编译成与当前平台匹配的机器码，并缓存起来。之后再次执行到这段代码就直接跑机器码，不再逐条解释。这种“边跑边编译”的思路，完美兼顾了启动速度和峰值性能，也是Java整个生态能支撑高性能服务的关键。
JIT还有分级编译概念，用多个层级逐步优化代码。低层级快速编译但优化程度低，高层级编译耗时更长但优化效果更明显。JVM会持续监控代码的执行频率，在合适的时机把代码升级到更高级别的优化编译。
运行期优化的自由度远超编译期，因为它能拿到实际运行的profile信息，比如哪些分支是热门分支、哪些对象没有被并发访问。JVM运行时优化可以做到方法内联、锁消除、逃逸分析、栈上分配等。这些优化不是对字节码做修改，而是对机器码做重写，背后的逻辑类似于“与其把菜谱背下来饭点现做，不如熟知常客口味提前备好半成品”。
2.3 运行期的动态能力：反射与动态代理
编译期是静态世界，一切类型在编译时确定。运行期是动态世界，JVM允许程序在运行时查询和操作类型信息，这就是反射。
反射能拿到类的构造器、方法、字段、注解，可以在运行期调用方法甚至访问私有字段，还可以直接构造不经过编译期创建的对象实例。这种动态性在处理框架配置、插件体系、依赖注入时不可或缺。但反射是一把双刃剑：方法调用比直接调用慢得多，类型检查大量推迟到运行期，很多低级错误在运行期才以异常形式暴露，长期在安全层面也有类包装器权限的隐患。因此生产环境里明智的做法是尽量在启动阶段或低频路径中使用反射，避免在超高并发循环里频繁调用。
与反射密切相关的动态代理，也是典型的运行期技术。动态代理在运行期动态生成代理类，代理类拦截方法调用，可以在不修改原有实现的情况下增加日志、鉴权、事务处理等横切逻辑。动态代理有两种常见实现方式：基于接口的方案用JDK原生能力生成代理类，基于类继承的方案用字节码框架在运行期修改字节码生成子类。前者只支持接口代理，后者更灵活但引入额外依赖。
2.4 运行期GC：内存生命周期的隐形管家
运行期另外一个重量级机制是垃圾回收（GC）。程序运行过程中不断创建对象，这些对象占用堆内存，失去引用后如果不回收，内存很快就被耗尽。GC负责自动追踪对象存活状态，回收不再可达的对象并整理内存碎片。
JVM提供的多种GC器各有特点，有的追求低延迟，有的追求高吞吐，有的针对超大堆做了分区优化。现代JVM默认的垃圾回收器多基于分代收集理论，把堆内存划分为新生代和老年代。新生代对象朝生夕灭，回收频率高；老年代对象存活得久，扫描频率低。调优JVM最常见的实操就是根据应用特点合理设置堆大小、新生代占比、GC器的选择。
理解GC对“编译期与运行期”这个话题很有帮助：编译期只关心静态代码正确性，不关心运行期内存管理；运行期则要处理对象生命周期、内存分配与回收，这里面任何一个环节异常都会直接表现为运行期错误，比如内存溢出、频繁Full GC导致的高延迟。
3. 编译期和运行期最容易搞混的几个边界地带
3.1 静态分派与动态分派：同一个方法调用，谁说了算
方法重载在编译期就确定了调用版本，这叫静态分派。再看方法重写，子类实例调用被重写的方法时，到底执行父类版本还是子类版本，运行期根据实际对象类型决定，这叫动态分派。
举个最常见的场景。定义基类Shape和两个子类Circle、Triangle，都实现draw()方法。编译期见到变量声明类型是Shape，调用draw()时字节码里记录的调用目标是Shape.draw()。运行期执行到这行代码时，JVM拿到实际对象类型，发现是Circle，就去Circle类里寻找draw()并调用。这样一来，编译期的方法签名是静态确定的，但实际方法体是动态派发的。
实际开发里让我印象最深的坑是“重载与重写混用”。有人以为重载会根据运行期实际类型来选择版本，结果写出来的代码走了完全错误的重载版本。重载决策完全发生在编译期，基于声明时类型；重写决策完全发生在运行期，基于实际运行时类型。这两件事是两套决策机制，千万别混为一谈。
3.2 编译期常量与运行期常量：改一个数字引发的“血案”
Java里用static final修饰的基础类型和String类型，如果值在编译期就能确定，编译器会把它视为编译期常量并直接“内联”到使用处。这种内联带来的一个诡异现象是，你修改了常量的值，但依赖方不重新编译，运行期间使用的仍然是被内联进去的旧值。
我用一个实际项目举例。某个公共模块里定义了public static final int MAX_SIZE = 100;，业务模块里大量使用这个常量。后来常量改成200，只重新构建公共模块、把新jar替换上去，业务模块没有重新编译。这时候业务模块运行时，MAX_SIZE仍然是100。因为编译器把MAX_SIZE当成立即数写进了业务模块的字节码里，它压根不会去读取公共模块的最新值。
解决方式有两种：一是常量修改后，所有依赖方一起重新全量编译，这种做法在团队协作时往往难以保证；二是把这类可能变化的常量改为运行期读取，比如通过枚举、配置中心、静态方法调用等方式取值。只要值是从运行期动态获取的，修改就不需要依赖方重编。
3.3 泛型的编译期检查与运行期擦除
泛型是Java在编译期强化类型安全、在运行期抹除类型信息的经典案例。用“List<String>”声明一个列表，编译期会严格检查向列表中放入的元素类型，防止插入非String对象。但当代码编译完成，泛型信息在字节码里基本被擦除，List<String>和List<Integer>在运行期看起来都是同一个裸类型List，JVM根本分辨不出它们原先带什么泛型参数。
正因为泛型擦除，泛型类在运行期无法直接获取“T的实际类型”。比如框架没有自定义TypeToken之类的规避手段之前，泛型做反序列化时经常拿到的是裸的LinkedHashMap，而不是目标类型对象。很多刚接触这种框架的人很困惑，为什么明明声明了泛型类型却转换失败，其实原因就是编译期没有把泛型信息固化到字节码里。
这种设计权衡的代价是显式的：编译期类型安全提高了，但运行期的类型灵活性被削弱。作为开发者，必须明白什么时候该借助泛型让编译器帮自己把关，什么时候需要借助运行时工具拿到完整的泛型类型信息。
4. 实际排查问题的踩坑实录
4.1 编译期通过为什么运行期还在报错
遇到“编译通过，一跑就炸”的场景，第一反应不应该是怀疑编译器有毛病，而是要审视哪里跨越了编译期和运行期的边界。
最常见的情形是依赖缺失。编译时候依赖了某个jar包，但运行时期Classpath里没包含这个jar，就会出现ClassNotFoundException。还有版本不一致，编译时用接口A的1.0版本，运行时的jar包已经是2.0且方法变了，结果抛出NoSuchMethodError。这类问题在微服务架构和复杂依赖体系里非常常见，排查的关键就是核对最终运行时Classpath的具体jar版本。
另一个高发场景是资源文件差异。编译期读配置文件、模板文件都没有问题，但运行期工作目录变了、资源打包路径变了，导致文件路径定位失败。这种错误跟代码逻辑本身关系不大，纯粹是运行环境与编译环境的差异造成的。
我的排查习惯是这样的：先把报错堆栈读完整，确认异常的精确类型，然后判断它属于“加载类失败”“方法签名不匹配”“类型转换失败”或“资源定位失败”中的哪一类。定位到类别后，侧重排查Classpath与依赖版本、框架配置与运行环境，而不是盲目去翻业务代码。
4.2 区分编译期报错和运行期报错的表现形式
编译期报错有一个鲜明特性：报错信息会精准指出失败的行号和列号，错误类型是“错误”级别的编译器消息，同时会附加具体原因，比如“找不到符号”“类型不兼容”“非法开始表达式”。这些错误不修复，连.class文件都生成不出来。
运行期报错则完全不同。它的报错位置处于代码执行到的那一行，不一定对应最初的根因，而且异常类型千奇百怪。比如空指针异常可能出现在任何一次成员访问上，数组越界异常可能跟循环边界计算有关。最迷惑的是，同一个逻辑，数据输入不同，有时正常、有时报错，没有固定的触发模式。
现场出现编译错误时，按照编译器提示逐条修就行，大部分编译器消息已经包含解决方案。现场出现运行期错误时，更多依赖日志、堆栈、监控、调试器。运行期错误的排查比编译期复杂得多，这也是为什么很多入门者觉得Java“坑多”，其实只是初学者把两类错误混在一起看不透。
4.3 类加载边界引发的线上事故重现
有一次线上事故让我对类加载边界印象极深。某服务升级一个新版本，代码改动其实很小，但引入了一个新的第三方库。发布后，进程反复出现某个类无法加载的报错，导致请求全部失败。
起初排查以为是缺包，检查classpath发现jar是存在的。后来用启动参数查看类加载日志，才发现问题出在父类加载文件的位置：新引入的类与旧依赖里的某个类存在同包同名，但父类加载器优先加载了旧依赖里的一个版本，这个版本缺新方法，导致新代码里的调用在链接阶段直接报错。
这类问题在编译期完全不可能发现，因为编译时用的是细粒度精确依赖，各个版本的jar之间不存在同名类冲突；运行期的类加载是“按名字全局查找”的，同名类会被最先找到的那个拦截，无法像编译期那样精细区分来源。从那次之后，我处理依赖冲突的方式就变了：升级依赖前先全量扫描依赖树，确认没有同包同名类、没有冲突的传递依赖版本。
4.4 动态代理和反射引发的隐蔽问题
动态代理和反射在运行期很灵活，但也有一类隐蔽问题让我吃过亏。某次写一个通用日志切面，用动态代理拦截第三方类的调用，结果服务起来之后怎么都切不进去。后来排查发现，目标对象根本不是一个代理可覆盖的接口实现，JDK动态代理的底层要求“被代理类必须实现接口”，切的是具体类而不是接口方法。
解决方式要么换成字节码增强型代理，要么调整设计让目标类显式实现一个接口。这之后我养成了习惯：在引入代理方案前先确认被代理对象的类型形态，不要想当然地认为动态代理能代理一切类。
反射相关的坑则更多，最常见的几个是：字段名反射获取时拼写错误，运行期才暴露；方法的可见性不足，反射调用private方法前没有先置可访问标志；方法重载导致getMethod按参数类型找不到目标。这些错误全部是运行期错误，编译期一个都不提示，所以写反射代码时必须加严密的防御判断和异常捕获，而不是默认“一定调得通”。如果要对反射调用做高频调用，还应当考虑缓存Method对象或改用接口调用方式，性能差距非常明显。
5. 怎么在实际开发中用好这两个阶段的特性
5.1 代码设计时要刻意区分“编译期确定”与“运行期确定”
写代码之前，先问自己一个问题：这段逻辑是要在编译期就确定下来，还是运行期才允许变化？
如果答案是在编译期确定，就尽量利用强类型约束、泛型、常量、接口等手段，让编译器帮你尽早做检查。比如多处复用的固定数值，能满足编译期常量就直接用常量；需要根据状态机跳转的逻辑，就多用枚举类型和模式匹配，编译器会提示你遗漏分支。
如果答案是运行期确定，就引入合理的动态机制，比如配置中心、策略注入、SPI扩展、反射钩子。动态机制带来灵活性的同时，必须有清晰的错误处理和降级方案。
我发现很多“老码”陷入困局，就是因为它错把“运行期该变的东西”硬编码成编译期常量，或者把“编译期该固定下来的类型约束”强行搞成运行期反射。这个判断做错了，后边就是持续打补丁和逃不掉的运行期BUG。
5.2 审查和测试时按阶段分配精力
做代码评审时，不要只盯着业务逻辑，还要带着“编译期/运行期”的框子去挑问题。
我会重点看这些方面：是否存在“编译期常量被依赖方内联”的隐患；泛型和类型参数是否被广泛使用但有些地方被迫使用了不安全的强制类型转换；反射调用点是否缺少兜底逻辑；动态代理的实现方式与被代理类是否匹配；新增依赖是否引入了类加载冲突风险；是否有大量运行期校验可以提前搬到编译期用类型解决。
在写测试的时候，单测尽量覆盖编译期的类型约束和边界情况，集成测试则重点覆盖运行期加载、反射、动态代理、类加载冲突、配置文件变化。按照这个维度分配测试精力之后，线上事故明显少了很多。
5.3 工具链：用javap和运行时日志定位阶段问题
说到排查工具，javap是我最常用的一个。通过javap -v反编译.class文件，可以查看到字节码层面的常量池、方法签名、注解信息，也能直观看到编译期常量是否已经被内联、泛型是否被擦除、静态分派选择了哪个方法版本。做依赖差异排查时，这个工具非常直观。
运行期的排查则依赖JVM提供的各种观测手段。启动时加-verbose:class可以打印类加载明细，-verbose:gc可以看到GC日志，-XX:+PrintCompilation可以查看JIT编译了哪些方法。线上运行时的执行情况，可以通过可观测性工具查看线程栈、堆内存、GC频率，以及动态代理类的实际结构。
还有一个容易忽略的小技巧：查看字节码兼容性时，用javap直接对比新旧两个版本的.class文件，能够精准判断是不是“编译期常量内联”导致的旧值残留，还是方法签名修改导致的NoSuchMethodError。这个方法比肉眼比对源码快得多。
5.4 一个容易忽视的Java新特性视角
越来越多人注意到，Java近几个版本开始尝试在编译期引入更强劲的类型推断和模式匹配能力，部分原来必须运行期反射才能搞定的场景，现在可以用编译期就完成的类型安全方式解决。从开发者的体验来讲，从反射走向编译期的过程也是错误“前置暴露”的过程，不值得过度追求“运行期万物皆动态”。
编译期能力增强和运行期能力保留并不矛盾。编译期负责在开发阶段给到最严格的类型安全保障，运行期负责在部署后提供最灵活的运行时行为，两边各司其职，才是Java生态最成熟的用法。
6. 总结的经验，或者说还值得记录的体会
做Java开发这么多年，我最深的一个体会是：理解编译期与运行期，本质上是在理解一套“及早失败与延迟成功”的平衡机制。编译器帮你拦下的每个错误，都是在替你节省两小时线上排查时间；运行期给你的灵活度，每一项也都对应着隐藏的排查和安全成本。能把这两者的边界看清楚，很多疑难杂症其实都能一眼定位根因。
最后分享一个我个人觉得很有用的技巧：写代码时养成一种“标注习惯”，对每个关键类或字段，在心里打一个标签——这个是编译期决定的，那个是运行期决定的。尤其是常量、泛型、反射调用、动态代理这几类高发地，坚持这样标注一段时间后，你对全项目运行行为的预判能力会上升一个档次，代码评审时也自然能看到比别人更多一层的问题。
