验证阶段首先校验Class文件格式合法性，包括魔数必须为0xCAFEBABE、版本号在JVM支持范围内、常量池结构合法、整体布局有效及类关系基础约束，未通过则抛出ClassFormatError并终止加载。
类加载过程中的验证阶段，对Class文件格式的校验是整个安全防线的第一道关口。它不关心代码逻辑是否正确，只严格检查字节流本身是否“长得像一个合法的Java类”——就像海关查验护照：先看是不是标准尺寸、有没有伪造涂改、印章是否匹配，再决定是否放行。
校验什么：从魔数到结构完整性
这一阶段完全基于二进制字节流进行，不依赖任何语义理解。主要检查项包括：
- 魔数（Magic Number）：必须以 0xCAFEBABE 开头，这是Java Class文件的固定“身份证”，不是这个值直接拒收；
- 版本号：主版本号和次版本号需在当前JVM支持范围内（例如JDK 17对应主版本61），超前或过旧都会失败；
- 常量池结构：检查常量类型tag是否合法（如CONSTANT_Class_info、CONSTANT_Utf8_info等），UTF-8字符串是否编码合规，是否存在循环引用或损坏的字节序列；
- 整体布局有效性：字段表、方法表、属性表的起始位置、数量、长度是否对齐且无重叠，访问标志（如ACC_PUBLIC、ACC_FINAL）是否与上下文冲突（比如接口里出现ACC_STATIC方法）；
- 类关系基础约束：确保类有且仅有一个父类（Object除外），final类未被继承，同一接口未被重复声明等。
为什么这一步不能跳过（除非你明确知道后果）
该阶段是后续所有验证的前提。只有通过格式校验，字节流才会被解析并存入方法区，形成JVM内部的数据结构。后面的元数据、字节码、符号引用验证，都基于方法区里的结构展开，不再操作原始字节流。换句话说：格式校验不过，连内存都不让进，更谈不上执行。
它本质上是一种“静态语法过滤”，成本低、见效快，能拦截大量因编译错误、传输损坏、恶意篡改导致的非法文件，避免后续更复杂的分析浪费资源或引入风险。
失败时会发生什么
一旦格式校验失败，JVM会立即抛出 ClassFormatError，并终止类加载流程。常见报错信息如：
- java.lang.ClassFormatError: Incompatible magic value（魔数不对）
- java.lang.ClassFormatError: Unsupported major.minor version（版本不兼容）
- java.lang.ClassFormatError: Invalid constant pool entry（常量池异常）
这类错误通常出现在跨JDK版本部署、手动编辑class文件、或使用非标准编译器生成字节码的场景中。
