平台无关二进制/表示可选方案及选型权衡技术咨询

其他主流可选方案 #

• 通用中间语言（CIL，.NET 运行时字节码）：.NET生态的跨平台字节码，支持C#、F#等多语言编译输出，目前.NET 5+已经实现全主流操作系统、架构的兼容覆盖。
• GraalVM Polyglot IR：支持多语言互操作的中间表示，除JVM字节码外，还可承载JS、Python、Ruby等语言的编译结果，实现多语言无开销互调。
• eBPF字节码：原本为内核观测场景设计的跨架构字节码，目前已经扩展到内核态通用计算、用户态运行等场景，可实现跨架构、跨操作系统的轻量执行。
• Protobuf/FlatBuffers 结构化序列化表示：如果是数据层的平台无关场景，这类二进制序列化格式是跨语言、跨平台传输存储结构化数据的主流方案，同类可选还有Apache Avro、CBOR等。
• QEMU目标架构二进制+用户态模拟：如果需要复用现有原生二进制，打包单架构原生二进制配合轻量QEMU用户态模拟也是生产环境常用的跨架构兼容方案。

各方案核心维度权衡对比 #

以下对比覆盖你提到的四个核心关注维度：向后兼容性、性能、代码密度、开源属性。

1. WebAssembly (Wasm) #

• 向后兼容性：极高，核心规范迭代严格保证向前兼容，1.0版本发布至今没有破坏性变更，不同 runtime 对基础规范的支持一致性极强。
• 性能：接近原生，AOT编译后普遍能达到原生性能的80%~95%，沙箱执行开销极低，JIT模式性能也优于多数解释型字节码。
• 代码密度：极高，采用紧凑变长二进制编码，相同逻辑的体积比原生二进制小30%~50%，远高于JVM、CIL等字节码。
• 开源属性：完全开源，W3C主导规范制定，所有主流 runtime（Wasmtime、V8、Wasmer等）都采用MIT/Apache等宽松开源协议，无使用限制。

2. 带JIT/AOT的LLVM IR #

• 向后兼容性：较低，LLVM大版本迭代经常调整IR的格式、语义，不同版本的IR互不兼容，没有长期兼容性保障，仅适合同版本工具链内部使用。
• 性能：极高，作为工业级编译器中间表示，优化程度和原生编译完全一致，AOT编译后就是原生性能，是所有方案里的性能天花板。
• 代码密度：中等，文本格式IR冗余度很高，bitcode格式紧凑度一般，体积大于Wasm和原生二进制。
• 开源属性：完全开源，LLVM项目本身采用Apache 2.0协议，无使用限制。

3. JVM字节码 #

• 向后兼容性：极高，字节码规范近30年几乎没有破坏性变更，20年前编译的字节码现在仍可在最新JVM上正常运行。
• 性能：较高，HotSpot等JVM的JIT编译后峰值性能可达原生的70%~90%，但冷启动开销大，解释模式性能较低。
• 代码密度：中等，采用定长+变长混合编码，体积比原生二进制小，但比Wasm大20%~40%左右。
• 开源属性：完全开源，OpenJDK是官方参考实现，采用GPLv2 + Classpath例外协议，商用无压力，也有大量第三方开源实现。

4. .NET CIL字节码 #

• 向后兼容性：高，.NET Core之后字节码规范稳定性很强，老版本.NET Framework的字节码在.NET 5+上也有兼容层支持，破坏性变更极少。
• 性能：较高，和JVM处于同一梯队，RyuJIT编译后峰值性能接近原生，Native AOT模式可达到原生性能，冷启动表现优于JVM。
• 代码密度：中等，和JVM字节码密度接近，略优于JVM。
• 开源属性：完全开源，.NET Runtime采用MIT协议，无使用限制。

5. eBPF字节码 #

• 向后兼容性：中等，内核版本迭代会新增eBPF特性，低版本内核不支持高版本新指令，但基础指令集兼容性稳定，用户态eBPF runtime兼容性更好。
• 性能：极高，内核态JIT编译后是原生性能，开销比系统调用低一个数量级，用户态runtime编译后也接近原生。
• 代码密度：极高，指令集非常精简，二进制体积比Wasm还小，适合资源受限场景。
• 开源属性：完全开源，Linux内核原生支持，所有用户态runtime（libbpf、bpftime等）都采用宽松开源协议。

6. Protobuf/FlatBuffers 序列化表示 #

• 向后兼容性：极高，规范设计原生支持向前向后兼容，新增、删除字段不会破坏老版本的解析逻辑。
• 性能：极高，序列化反序列化开销极低，FlatBuffers可实现零拷贝解析。
• 代码密度：极高，紧凑二进制编码，体积比JSON小30%~70%。
• 开源属性：完全开源，官方实现采用BSD/MIT等宽松协议，无使用限制。

内容的提问来源于stack exchange，提问作者Prathyush