关于Kotlin Native代码跨JVM、JS等平台编译的疑问

有效的Kotlin Native代码无法直接用于编译JVM、JS等其他平台，核心差异体现在以下几点：

• 平台专属API依赖：Kotlin Native包含大量针对原生平台（如iOS、Linux）的专属API，比如kotlinx.cinterop包下用于和C/C++互操作的代码，这类API在JVM/JS环境中完全不存在，直接编译会触发未定义符号或API不存在的错误。
• 内存模型差异：Kotlin Native采用**自动引用计数（ARC）**管理内存，还提供freeze()这类处理并发可变状态的函数；而JVM用垃圾回收（GC），JS是标记清除GC+引用计数混合模型，三者的内存管理逻辑完全不兼容，Native代码里的内存相关操作在其他平台无法正常运行。
• 底层编译目标差异：Kotlin Native编译为机器码，JVM编译为字节码，JS编译为JavaScript代码。比如Native中的UInt是直接映射到平台原生无符号整数，JVM没有原生无符号类型，只能靠包装类模拟，直接复用代码会导致行为不一致。

至于为何Kotlin多平台库需要分别实现JVM、JS、Native版本，而非直接用Native代码适配所有平台，原因如下：

• 平台最优性需求：不同平台有各自的高性能API。比如文件IO操作，JVM用java.io包效率最高，JS只能用浏览器/Node.js的文件系统API，Native可以直接调用系统C函数。如果强行用Native逻辑适配其他平台，只能通过兼容层模拟，会大幅降低性能，还可能出现兼容性问题。
• 平台特性利用：多平台库通常需要利用各平台的独有特性。比如加密库，JVM可以用内置的javax.crypto，JS用Web Crypto API，Native调用OpenSSL，这样每个平台的安全性和性能都能达到最优，远胜用Native代码在其他平台上模拟的方案。
• 减少维护复杂度：强行用Native代码覆盖所有平台，需要搭建庞大的兼容层来模拟Native的API和内存模型，这会增加库的体积，引入更多潜在bug，维护成本极高。分开实现各平台版本，代码逻辑更清晰，每个平台的代码只处理自身逻辑，更易迭代和维护。

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