.class文件合法性首看前4字节魔数CAFEBABE，再查5–6字节次版本号和7–8字节主版本号（如Java 8为52，Java 17为61），须按大端序解析；常量池以2字节计数开头（索引从1起），每项首字节为tag决定结构，引用型常量需间接查CONSTANT_NameAndType_info；javap输出经语义还原，与原始字节不一致，调试需对照-javap -v与hexdump；解析易崩于偏移10处、tag字节、UTF-8 length（u2）、access_flags（u2）等关键位置，属性嵌套深，须严格按JVM规范处理字节长度与对齐。
怎么看 .class 文件开头的魔数和版本号
Java 类文件是否合法，第一眼就看前 4 字节是不是 CAFEBABE —— 这不是彩蛋，是硬性校验。JVM 启动时直接拒绝非此魔数的文件，连错误提示都懒得给你（抛 ClassFormatError，但不说明具体哪错了）。
紧跟着魔数的是 4 字节版本号：第 5–6 字节是次版本号（minor version），第 7–8 字节是主版本号（major version）。比如 Java 8 编译出的类，major version 是 52；Java 17 是 61。用 javap -verbose 能看到，但更直接的是用十六进制查看器打开 .class 文件，定位前 8 字节。
- 别靠文件名或编译命令猜版本——
javac -source 8 -target 8和-source 11 -target 8都可能生成major version 52，关键看-target - 版本错配时，高版本 JVM 可以运行低版本 class，但低版本 JVM 加载高版本 class 会直接报
UnsupportedClassVersionError，错误信息里带的数字就是那个major version - 注意字节序：Java class 文件全程大端（Big-Endian），读版本号时别按小端解析，否则
52会变成13312
常量池 entry 的 tag 和结构怎么对应上
常量池是 class 文件最复杂的部分，开头 2 字节是常量池计数（constant_pool_count），注意它比实际条目多 1 —— 索引从 1 开始，0 不使用。每项开头 1 字节是 tag，决定了后续字段长度和含义。
常见 tag 值：7 是 CONSTANT_Class_info（存类名索引），1 是 CONSTANT_Utf8_info（存字符串字节），9 是 CONSTANT_Fieldref_info（含类、名称、描述符三个索引）。一旦 tag 识别错，整个后续偏移全乱。
立即学习“Java免费学习笔记（深入）”；
- 别跳过
constant_pool_count直接读 —— 它决定了要循环多少次，少读或多读都会导致后续结构错位 -
CONSTANT_Utf8_info的 length 字段是 u2（2 字节），但 UTF-8 字节流本身可能含 \0，不能当 C 字符串处理；用String(byte[], StandardCharsets.UTF_8)解码才安全 - 引用型常量（如
Fieldref、Methodref）里的 name_and_type_index 指向的是CONSTANT_NameAndType_info，不是直接指向字符串 —— 中间多一层间接，容易漏跳
为什么用 hexdump 看常量池老是对不上 javap 输出
因为 javap 做了语义还原：它把 CONSTANT_Class_info 索引转成类名字符串，把 CONSTANT_Methodref_info 拆成“类.方法:描述符”，而原始字节里全是索引数字。你用 xxd MyClass.class | head -20 看到的是一串整数，不是可读名。
比如 javap 显示 java/lang/Object."，字节里可能是：tag 10 → class_index 5 → name_and_type_index 12，然后你得去查索引 5 对应哪个 CONSTANT_Utf8_info，再查索引 12 指向的 name 和 descriptor 分别是什么。
- 调试时建议先用
javap -v输出带常量池索引的完整版，对照着 hexdump 看，比纯猜高效得多 - 某些工具（如
javap -c）会省略常量池细节，必须加-v才显示全量结构 - 注意常量池里
CONSTANT_Integer_info和CONSTANT_Float_info都占 4 字节，但CONSTANT_Long_info和CONSTANT_Double_info各占 8 字节且会占用两个连续索引（下一个索引无效），这个空洞容易被忽略，导致后续索引整体偏移
手写解析器时最容易崩在哪几个字节位置
崩点往往不在逻辑复杂处，而在边界字节的类型误判上。比如把 u2 当 u4 读，或者把某个 tag 对应的结构长度记错，一个字节偏差，后面全废。
最常翻车的位置：常量池计数之后的首项起始位置（偏移 10）、每个常量池项开头的 tag 字节、CONSTANT_Utf8_info 的 length 字段（u2）、方法表（methods_count）之前的访问标志（access_flags，u2）——这些地方一旦读错类型，后续所有结构解析都会雪崩。
- 别信“大概长这样”——哪怕只差 1 字节，
CONSTANT_MethodHandle_info（tag15）和CONSTANT_MethodType_info（tag16）的字段布局完全不同，混了就解析失败 - 字段表、方法表、属性表都有自己的 count + 表体结构，但 count 字段长度不统一：有的是 u2，有的是 u4（比如
attributes_count是 u2，但某些 attribute 内部的数组 count 可能是 u4），必须严格按 JVM Spec 查 - 属性（attribute）嵌套深：比如
Code属性里还有exception_table_length和attributes_count，层层嵌套下，栈式解析比递归更稳，也更容易定位崩在哪一层
