字节码文件是JVM唯一能直接执行的二进制指令格式，非机器码也非源代码；编译Main.java生成Main.class，可用javap -c查看指令；常见错误包括类未生成、路径/大小写错误、JDK版本不匹配；跨平台因JVM屏蔽系统差异，但JNI和硬编码路径会破坏该特性；JIT动态编译热点代码提升性能，字节码本身也支持编译期与运行时优化。
字节码文件是Java实现跨平台的“通用中间语言”，不是机器码，也不是源代码，而是JVM唯一能直接执行的二进制指令格式。
字节码文件长什么样？怎么确认它真生成了
你写完 Main.java，执行 javac Main.java 后，只要没报错，当前目录下就会多一个 Main.class——这就是字节码文件。它不能用文本编辑器正常阅读，但可以用 javap -c Main.class 看到人类可读的指令，比如 iconst_1、istore_1、invokevirtual 这类操作码。
常见错误现象：
- 执行
java Main报错Could not find or load main class Main：多半是Main.class根本没生成，或当前路径不对，或类名/文件名大小写不一致（Linux/macOS 对大小写敏感） - 运行时抛
UnsupportedClassVersionError：说明编译用的 JDK 版本高于目标 JVM 支持的版本，比如用 JDK 21 编译，却在 JRE 8 上运行
为什么改个操作系统不用重编译
因为 .class 文件里没有 Windows 的 DLL 调用、也没有 Linux 的 syscalls，它只包含面向 JVM 指令集的抽象操作，比如 “压栈”、“调用方法”、“跳转”。不同平台的 JVM 各自负责把同一句 invokevirtual java/io/PrintStream.println 翻译成 Windows 的 WriteConsoleA 或 Linux 的 write(1, ...)。
立即学习“Java免费学习笔记（深入）”；
关键点：
- JVM 是平台相关的本地程序（Windows 上是
java.exe，Linux 上是java可执行文件），但对外接口和字节码规范完全一致 - Java 标准类库（如
java.io.File）在不同 JVM 中有不同底层实现，但行为被规范严格约束，对开发者透明 - 一旦用了 JNI（
System.loadLibrary(...)），就立刻打破跨平台性——.so 和 .dll 无法通用
字节码不是“慢”的代名词：JIT 怎么悄悄提速
很多人以为字节码靠解释执行所以慢，其实 HotSpot JVM 默认会把反复执行的方法（比如循环体、高频 getter）动态编译成本地机器码，缓存起来复用。这个过程对开发者完全无感，也不需要额外配置。
但要注意：
- 刚启动时（前几秒）确实以解释模式为主，所以微基准测试（如
JMH不预热）容易误判性能 -
java -Xint强制纯解释执行，仅用于调试或极端场景，日常绝对不要加 - 字节码本身支持优化：javac 已做常量折叠、基本控制流简化；JVM 运行时还会做内联、逃逸分析等高级优化
真正容易被忽略的是：跨平台不等于“零适配”。比如硬写 "C:\\data\\log.txt" 在 Linux 上会失败；又比如依赖系统默认字体渲染 GUI，macOS 和 Windows 效果可能明显不同——这些都不是字节码或 JVM 的问题，而是开发者没隔离平台差异。
