jvm加载class文件时首先校验魔数和主次版本号：前4字节必须为0xcafebabe，否则抛classformaterror；随后2字节次版本号通常为0，2字节主版本号须在jvm支持范围内，否则抛unsupportedclassversionerror。
JVM 在加载 class 文件时，第一件事就是做底层格式校验：先看魔数对不对，再看版本号能不能认。这不是可选步骤，而是硬性准入门槛——不通过就直接抛 ClassFormatError 或 UnsupportedClassVersionError，连类结构解析都不会开始。
魔数校验：4 字节固定标识，错一个字节就拒载
每个合法 .class 文件开头必须是 4 字节十六进制 CA FE BA BE（大端序，即内存中按此顺序排列）。这个值没有语义含义，纯属“身份令牌”。JVM 启动类加载器后，会直接读取前 4 字节比对：
- 若不是
0xCAFEBABE，立刻终止加载，抛出java.lang.ClassFormatError: Incompatible magic value； - 错误提示通常不带具体偏移信息，因为校验发生在解析最前端，JVM 连常量池都还没打算读；
- 常见误触发场景包括：文件被截断、UTF-8 BOM 污染（如用文本编辑器另存为）、混淆/加固工具改写头部（部分安全方案会主动破坏魔数，需结合工具链判断是否“有意非法”）。
主次版本号解析：紧随魔数的 4 字节，决定能否运行
魔数之后第 5–6 字节是次版本号（minor version），第 7–8 字节是主版本号（major version），均为无符号 16 位整数，大端存储。JVM 校验逻辑如下：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 次版本号通常为 0（JDK 1.1 起主流编译器均设为 0），JVM 一般不校验其合法性，仅作保留字段；
- 主版本号是关键：它对应 JDK 编译版本（如 52→JDK 8，55→JDK 11，61→JDK 17，65→JDK 21）；
- JVM 只接受主版本号 ≤ 自身支持的最大版本且 ≥ 规范定义的最小有效值（当前 OpenJDK 实现最低支持 45，即 JDK 1.1）；
- 若主版本号超出 JVM 能力范围（比如用 JDK 21 编译的 class 在 JDK 17 上运行），抛
java.lang.UnsupportedClassVersionError； - 规范未强制要求主版本号为偶数，但所有正式 JDK 发布版本均使用偶数值；奇数主版本号极大概率表示手工构造或生成异常，可作为辅助判据。
校验发生的实际位置与时机
该校验发生在类加载的“加载”阶段早期，具体在 ClassLoader.defineClass() 调用内部，由 JVM 原生代码（如 HotSpot 的 fileStream::read_u4() 和 verify_magic_and_version() 类似逻辑）完成：
- 不依赖任何 Java 层代码，纯 C/C++ 级别字节读取与比对；
- 只读前 8 字节，不做内存映射或完整解析，效率极高；
- 失败时不会记录日志细节，默认不输出堆栈（除非开启
-XX:+TraceClassLoading或调试模式）； - javap -verbose 输出的 version 信息，是解析成功后的回显，不能替代原始字节校验。
快速验证方法（非运行时）
开发者可在部署前用轻量方式预检：
-
xxd -l 8 YourClass.class：直接查看前 8 字节，确认是否为ca fe ba be 00 00 xx xx； -
javap -verbose YourClass.class | grep -i "major\|minor"：依赖 JDK 工具，但需 class 可被当前 JVM 加载； - 写个小程序用
DataInputStream读前 8 字节，手动组合magic = (b0，再比对版本范围——适合集成进 CI/CD 校验脚本。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
