字节码是Java源代码编译生成的、面向JVM的平台无关二进制指令，以CAFEBABE魔数开头，含主版本号决定JVM兼容性；通过javap可查看getstatic、ldc等指令；其跨平台依赖.class文件与各平台JVM的规范契约，执行时由JVM动态选择解释或JIT编译。
字节码是 Java 源代码编译后生成的、面向 JVM 的中间二进制指令，它不是机器码，也不依赖操作系统或 CPU 架构——这才是 Java “一次编写，到处运行” 的真实载体。
字节码到底长什么样？怎么验证它生成了
它不是文本，而是严格格式化的二进制数据（.class 文件），但可通过工具“看懂”关键结构。比如编译一个最简类：
public class Hello {
public static void main(String[] args) {
System.out.println("Hi");
}
}
执行 javac Hello.java 后，会生成 Hello.class；用 javap -c Hello.class 可看到类似这样的字节码指令：
0: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream; 3: ldc #3 // String Hi 5: invokevirtual #4 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
这些指令（如 getstatic、ldc）是 JVM 的“汇编语言”，统一且平台无关。
立即学习“Java免费学习笔记（深入）”；
- 魔数
CAFEBABE开头：所有合法.class文件前 4 字节固定，JVM 靠它快速识别文件类型 - 主版本号（
major_version）决定兼容性：JVM 只能运行 ≤ 自身支持版本的字节码（例如 JDK 17 的 JVM 不能直接运行 JDK 21 编译出的.class） - 反编译不等于源码还原：
javap显示的是指令流，不含变量名、注释、控制结构缩进等源码信息
为什么 .class 文件能跨平台，而 .java 不能直接跨
核心区别在于：字节码是“写给 JVM 听的”，而 JVM 是“各平台自己写的翻译官”。
-
.java是纯文本，可复制到任意系统，但必须用对应平台的javac重新编译——因为javac本身是平台相关程序（Windows 上是javac.exe，Linux 上是javac可执行文件） -
.class是标准二进制，只要目标系统装有**版本兼容的 JVM**（如 OpenJDK 17 for Linux / Windows / macOS），就能原样加载执行 - 真正跨平台的不是语言，也不是开发者写的代码，而是
.class文件 + JVM 规范的契约关系
常见误操作：把 Windows 下编译的 MyApp.class 复制到 Linux，却报 UnsupportedClassVersionError —— 这不是平台问题，而是 Linux JVM 版本太低，不支持该字节码主版本号。
字节码如何被真正执行：解释 vs JIT 的实际影响
JVM 不是简单“翻译一遍就完事”，它在运行时动态选择执行策略：
- 解释执行：逐条读取字节码，实时转成机器指令。启动快，适合冷启动场景（如 CLI 工具），但重复调用时效率低
-
JIT 编译：对高频执行的方法（如循环体、热点
toString()）自动编译为本地机器码并缓存。后续调用直接走机器码，性能接近 C/C++ - 你无法手动开关 JIT，但可通过
-XX:+PrintCompilation查看哪些方法被 JIT 了
这意味着：同一个 .class 文件，在不同负载下，实际执行路径可能完全不同——刚启动时是解释执行，跑几分钟后关键逻辑已变成机器码。
最容易被忽略的一点：字节码的“平台无关”只保证格式和语义，不保证行为完全一致。比如 File.separator 在 Windows 返回 \，Linux 返回 /，这是 JVM 实现层根据 OS 主动适配的，而非字节码里写死了什么——跨平台的细节，最终仍由 JVM 背书。
