java跨平台靠的是.class字节码与jvm配合，而非源码或操作系统直接执行；.class是jvm专用中间格式，需对应版本jvm加载，绕过jvm调用系统api则破坏跨平台性。
Java跨平台不是靠源代码直接运行
Java能“一次编写，到处运行”，根本不是因为 .java 文件本身能跨系统执行——它连Windows和Linux的可执行格式都不兼容。真正起作用的是编译后生成的 .class 文件，它是一种与平台无关的中间表示，只面向JVM设计。
关键点在于：不同操作系统的JVM各自实现了同一套字节码规范，但底层调用的是各自系统的API（比如文件IO、线程调度）。所以你写的 System.out.println("hello") 在Windows上由HotSpot调用Win32 API，在Linux上则调用glibc接口，而字节码指令本身完全没变。
为什么.class文件不能被操作系统直接加载
.class 文件不是机器码，也不是PE或ELF格式，操作系统内核根本不认识它的结构。它没有入口地址、没有段表、不包含系统调用编号，连最基本的加载器都拒绝识别。
常见错误现象：
- 直接双击 MyApp.class → 提示“无法打开此文件”或“找不到关联程序”
- 在终端执行 ./MyApp.class → 报错 Permission denied 或 Exec format error
- JVM才是唯一能解析
.class的“解释器+即时编译器”组合体 - 没有JVM，
.class就是一堆无意义的二进制数据（虽然可以用javap -v反汇编看结构） - 不同JDK版本生成的
.class有版本号（如52.0对应Java 8），高版本JVM通常能向下兼容，但低版本JVM加载高版本字节码会报UnsupportedClassVersionError
javac和java命令到底在做什么
javac 不是“编译成机器码”，而是把 .java 翻译成符合JVM规范的字节码；java 命令也不是“运行Java程序”，而是启动一个JVM实例，并把指定的 .class 文件交给它加载执行。
立即学习“Java免费学习笔记（深入）”；
实操中容易忽略的细节：
-
javac输出的.class文件名必须严格匹配类声明中的public class名，否则java找不到主类 -
java MyApp中的MyApp是类名，不是文件名，也不能带.class后缀 - 如果类在包里（如
com.example.Main），必须按目录结构存放，并用java com.example.Main运行，当前路径需是包根目录 -
java -cp指定的是类路径，不是jar包内部路径；jar包里的.class仍需遵循包结构
JVM不是万能翻译器，本地依赖照样破功
字节码跨平台的前提是：所有逻辑都走JVM提供的抽象层。一旦用了 System.loadLibrary() 加载 .dll 或 .so，或者调用 Runtime.exec() 执行系统命令，跨平台就立刻失效。
典型翻车场景：
- 代码里写死
Runtime.exec("cmd /c dir")→ Linux下直接抛IOException - 用JNI加载了Windows专用的
mylib.dll→ 换到Mac连JVM都启动失败 - 依赖某个JAR包内部硬编码了路径分隔符（如
"C:\config\data.txt"）→ Linux下文件找不到
这时候光靠JVM救不了你，得靠 File.separator、Paths.get()、条件化加载库等手段补位。
真正难的从来不是字节码能不能跑，而是你的代码有没有偷偷绕过JVM去碰操作系统。
