.class文件开头四字节必须为0xcafebabe，是jvm强制校验的魔数，不符则直接抛classformaterror；常量池存储编译期确定的字面量和符号引用，占文件体积超一半；code属性仅存在于有逻辑的方法中，含jvm执行的操作码序列。
class 文件开头四个字节为什么必须是 0xCAFEBABE
这是 JVM 识别合法 .class 文件的硬性签名，不是约定而是强制校验。读取时如果前四字节不是 0xCAFEBABE，JVM 直接抛 ClassFormatError，连版本号都不看。
常见错误现象：手动拼接字节码、用文本编辑器改 class 文件、或从网络下载损坏文件后，反编译时报错 Invalid magic number —— 先盯这四个字节。
- Java 8 及以后的 class 文件仍用这个魔数，没变过
- 某些混淆工具或字节码生成库（如 ASM）若配置出错，可能漏写魔数，导致类加载失败
- 用
xxd -c 16 -l 16 MyClass.class可快速验证：第一行开头应为ca fe ba be
常量池（Constant Pool）里存什么、为什么占 class 文件一半以上体积
常量池不是“字符串池”，它存的是编译期确定的所有字面量和符号引用，包括类名、字段名、方法名、描述符、整数/浮点数常量、UTF-8 字符串字面量等。每个项有类型标记（如 CONSTANT_Class_info、CONSTANT_Utf8_info），且索引从 1 开始（0 保留不用）。
使用场景：javac 编译时把所有符号信息集中登记在这里，运行时 JVM 通过索引查表解析类、字段、方法——所以它是整个字节码的“地址簿”。
立即学习“Java免费学习笔记（深入）”；
- 方法体越小、字符串字面量越多，常量池占比反而越大（比如大量日志语句含固定字符串）
- 反编译工具（如
javap -v）输出的Constant pool:部分，每行开头数字就是索引，注意跳过空槽（如CONSTANT_Long_info占两个索引位） - 修改 class 文件时若增删常量池项，必须同步更新
constant_pool_count字段和所有引用它的索引值，否则VerifyError
方法字节码藏在 Code 属性里，但不是所有方法都有
Code 属性只存在于有实际逻辑的方法中。接口默认方法、静态块、构造器都有；而接口抽象方法、本地方法（native）、桥接方法（bridge）没有 Code 属性，它们靠修饰符或其它属性标识行为。
性能影响：JVM 执行时，真正解释或 JIT 编译的是 Code 属性里的操作码（opcode）序列，比如 iload_0、invokevirtual。这些指令不直接对应 Java 源码行，而是基于操作数栈和局部变量表工作。
- 用
javap -c MyClass看到的汇编式输出，本质就是解码后的Code属性内容 -
max_stack和max_locals是编译期算出的硬上限，JVM 用它预分配栈帧空间；填错会导致VerifyError: stack size too large - 无参构造器若没显式写
super()，javac 会自动插入，所以哪怕空构造器也有Code属性和几条指令
反编译失败常见原因不是“加密”，而是结构破坏或版本越界
多数所谓“反编译不了”的 class 文件，其实没加密，只是被优化、混淆或跨版本生成。JVM 加载时只要结构合规就认，但反编译工具（如 CFR、JD-GUI、fernflower）依赖对常量池和属性结构的准确解析。
容易踩的坑：
- 用高版本 JDK 编译（如 JDK 17）生成的 class（主版本号 61），低版本反编译器可能不认识新属性（如
NestHost），直接报解析异常 - ProGuard 或 R8 移除了调试信息（
LineNumberTable、LocalVariableTable），导致反编译出的代码没行号、变量名变成arg0、local1，但逻辑仍可读 - 手工修改 class 后没重算属性长度、没对齐字节边界（如
Code属性要求 2 字节对齐），工具读到一半就崩溃
真要定位问题，先用 javap -verbose 看能否完整打印结构——能过这关，说明文件本身合法；过不了，优先查魔数、常量池格式、属性长度字段。
