字节码是JVM唯一能直接执行的指令，以CAFEBABE开头、格式严格，需经JVM加载校验后解释或JIT编译执行；它跨平台依赖.class文件与兼容JVM版本契约，但代码本身若含路径、编码、本地调用等平台强依赖逻辑，则无法保证跨平台运行。
字节码不是机器码，也不是源代码，它是JVM唯一能直接执行的指令
你写完 HelloWorld.java，用 javac 编译出来那个 HelloWorld.class 文件，就是字节码——它开头固定是 CAFEBABE 四个字节，后面跟着常量池、方法表、属性等严格格式化的二进制数据。JVM不认 .java，也不懂 x86 或 ARM 指令，它只认这套规范定义的字节码。
- 它不能被 CPU 直接运行，必须由 JVM 加载、校验、解释或 JIT 编译
- 它不包含变量名、注释、缩进，甚至默认没有行号信息（除非编译时加
-g） - 反编译工具（如 JD-GUI）还原出的 Java 代码只是“猜测”，
javap -c显示的getstatic、ldc、invokevirtual才是真实执行流
跨平台不是靠魔法，而是靠 .class + 版本兼容的 JVM 契约
把 Windows 上编译好的 MyApp.class 拷到 Linux，只要那里装了版本够高的 JRE，java MyApp 就能跑起来——不需要源码，也不需要重新编译。但这有个硬前提：JVM 支持该字节码的主版本号（major_version）。
- JDK 8 编译 → 主版本号 52；JDK 17 → 61；JDK 21 → 65
- 用 JDK 21 编译的
.class，在只装了 JDK 17 JRE 的 Linux 上运行，必然报错：java.lang.UnsupportedClassVersionError - 验证方式：
javap -v MyClass.class | grep "major"，再比对目标环境java -version
javap 是看懂字节码的唯一直接工具，别信反编译出来的“Java源码”
想确认某段逻辑是否真的被内联、某个字符串是不是真进了常量池、或者 finally 块怎么被拆成多个 goto，就得看 javap 输出，而不是依赖 IDE 反编译窗口里看着“很像源码”的结果。
-
javap -c MyClass.class：看每个方法的指令序列，比如iconst_1、istore_0、ifne -
javap -v MyClass.class：连常量池索引、异常表、LineNumberTable 都列出来，调试类加载失败或反射找不到字段时必用 - 生产环境 debug 要保留调试信息：编译加
-g，否则javap不显示行号，堆栈也全是Unknown Source
字节码能跨平台，但你的代码未必——路径、换行、本地方法才是真坑
字节码本身跨平台，不代表 Java 程序自动跨平台。很多“在 Windows 跑得好好的，Linux 一运行就空指针”问题，和字节码无关，而是代码写了平台强依赖逻辑。
立即学习“Java免费学习笔记（深入）”；
- 路径分隔符硬写
"\\\\"或"/"→ 应该用File.separator或Paths.get() - 读文件没指定字符集，依赖平台默认编码（Windows GBK / Linux UTF-8）→ 必须显式传
StandardCharsets.UTF_8 - 调用
Runtime.exec()执行 shell 命令，却在 Linux 写"cmd /c dir"→ 直接炸 - 用了 JNI 或
sun.misc.Unsafe等非标准 API → 在不同 JVM 实现（如 OpenJ9 vs HotSpot）上行为可能不一致
.class，而在你写的那几行 new File("C:\\data\\log.txt")。 
