验证阶段首先校验class文件魔数是否为0xcafebabe、主版本号是否在jvm支持范围内，未通过则抛出classformaterror或unsupportedclassversionerror并终止加载。
类加载的验证阶段对字节码文件的物理结构执行硬性校验，其中魔数与版本号是第一道也是最底层的防线——不通过即终止加载，不会进入后续任何解析流程。
魔数检查：JVM启动验证的“门禁刷卡”
JVM在读取.class文件头4个字节时，会逐位比对是否等于0xCAFEBABE。这不是字符串比较，而是无符号整型的精确二进制匹配：
- 若前4字节为CA FE BA BE（十六进制），视为合法入口，继续下一步；
- 若任意一位错（如CA FE BA BB或被截断只剩3字节），直接抛出java.lang.ClassFormatError: Incompatible magic value；
- 该检查发生在类加载器调用
defineClass()后、尚未分配内存前，属于纯I/O层校验，不依赖常量池或语义分析。
版本号检查：主次版本联合判定兼容性边界
魔数通过后，JVM立即读取第5–8字节，拆解为2字节次版本号（minor_version）和2字节主版本号（major_version）：
- 主版本号决定JVM能否执行该字节码：例如JDK 17对应61，JDK 21对应65；若运行时JVM主版本为61，但字节码主版本为65，则抛出UnsupportedClassVersionError；
- 次版本号目前几乎恒为0（自JDK 1.2起），仅作保留字段，实际校验中仅做存在性读取，不参与兼容性决策；
- 该检查在方法区尚未创建类结构前完成，属于元数据层面的静态比对，不触发任何类初始化逻辑。
物理检查的本质：零语义、纯字节流守门人
这两项检查共同构成“物理验证层”，特点是：
- 不解析常量池、不读取类名、不校验方法签名——只看固定偏移处的原始字节；
- 不依赖Java语言规范的高级语义，只遵循Class文件格式规范（JVM Spec §4.1）；
- 错误不可恢复：一旦失败，类加载器直接放弃该字节流，不会尝试修复、降级或跳过；
- 工具链可复现：用
xxd -c 16 Student.class | head -1或十六进制编辑器人工核对前8字节，结果与JVM完全一致。
这种设计确保了JVM能在毫秒级拒绝非法输入，把问题拦截在最外层，避免无效解析消耗资源或引入安全隐患。
