Java跨平台性依赖字节码与兼容JVM，非源码或二进制兼容；需注意JVM版本、厂商、路径/换行/编码、JNI、系统属性、JVM参数等平台差异。
字节码才是真正的跨平台载体
Java源文件（.java）经javac编译后生成的是.class文件，里面是标准化的字节码指令（如iconst_1、astore_0），不是Windows的EXE或Linux的ELF。只要JVM实现了JVM规范（JVMS），就能读取并执行这些字节码。
常见错误现象：
• 在Java 17编译的.class文件，在Java 8 JVM上抛出UnsupportedClassVersionError
• 用-target 11但忘了配-source 11，导致语法（如var）被拒绝
- 实操建议：始终显式指定编译目标版本，例如：
javac -source 11 -target 11 HelloWorld.java - 构建工具中（Maven）应配置
maven.compiler.source和maven.compiler.target，避免依赖环境默认值 - 不要假设“装了JDK就能跑”——JRE/JDK版本、厂商（OpenJDK vs Oracle vs Alibaba Dragonwell）都可能影响行为，尤其是GC策略、TLS默认版本等底层细节
路径、换行、编码：三类最常崩的“隐形平台依赖”
即使字节码能跑，文件操作、日志输出、文本解析仍可能在Windows/Linux/macOS上表现不一。
- 路径分隔符：硬写
"config/file.xml"在Windows下可能意外成功（因为Win也认/），但在某些JVM或容器环境下失败；正确做法是用File.separator或更现代的Paths.get("config", "file.xml") - 换行符：
"\n"在Windows上写入文件会导致Notepad显示为一行；应改用System.lineSeparator() - 字符编码：
new String(bytes)依赖系统默认编码，Mac是UTF-8，Windows旧版可能是GBK；必须显式传StandardCharsets.UTF_8
JVM本身不是银弹：兼容性陷阱在哪
不同JVM实现或版本对同一段字节码的解释可能有细微差异，尤其涉及：
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
立即学习“Java免费学习笔记（深入）”；
- 本地方法调用（JNI）：加载
libfoo.dll（Win）vslibfoo.so（Linux）需手动判断System.getProperty("os.name")，且二进制不可互换 - 系统属性和环境变量：比如
System.getenv("PATH")在macOS上叫PATH，但某些Docker镜像里可能为空；System.getProperty("file.encoding")不可信，永远自己指定 - JNI库路径：
System.loadLibrary("foo")依赖java.library.path，该路径在各平台默认值不同，生产部署时务必用-Djava.library.path=...显式设置
打包与部署：跨平台≠免配置
一个jar包理论上可在任意JVM上运行，但实际部署时往往卡在外部依赖上。
- GUI应用：Swing/JavaFX虽跨平台，但字体渲染、窗口装饰、高DPI缩放在各系统差异明显；JavaFX 17+已移除内置WebEngine，若用到WebView需额外打包WebView组件
- 容器化是当前最稳方案：用
openjdk:17-jre-slim基础镜像打包，屏蔽宿主机差异；但要注意glibc vs musl（Alpine）兼容性，避免JNI库崩溃 - 原生镜像（GraalVM）看似“彻底跨平台”，实则牺牲了反射、动态类加载等能力，且每个目标平台需单独构建（
native-image --target=linux-amd64）
最容易被忽略的一点：JVM参数不是跨平台通用的。比如-XX:+UseZGC在Java 11+ Linux可用，但在macOS上直到Java 15才支持，Windows更是晚至Java 16——没验证就上线，服务直接起不来。
