JetBrains推出的Compose Multiplatform让Kotlin开发者可以用同一套声明式UI代码，构建运行在桌面操作系统和浏览器中的应用。对于团队而言，这意味着业务逻辑和界面代码可以大量复用，只在平台差异处做少量适配。这篇文章从工程搭建讲起，逐步覆盖桌面端与Web端的接入方式、能力边界以及实际开发中容易踩的坑。
一、工程结构与共享代码的组织方式
一个典型的Compose Multiplatform工程采用Gradle多模块结构。核心是一个共享模块（common模块），里面存放UI代码和业务逻辑，再通过source set针对不同平台做差异化实现。桌面应用模块和Web入口都依赖这个共享模块，各自提供平台相关的启动入口。
在共享模块的build.gradle.kts中，需要声明目标平台。桌面端可以复用JVM目标，而Web端则需要声明wasmJs或js目标。一个常见的配置如下：
kotlin {
jvm("desktop")
wasmJs {
browser {
commonWebpackConfig {
outputFileName = "app.js"
}
}
binaries.executable()
}
sourceSets {
val commonMain by getting {
dependencies {
implementation(compose.runtime)
implementation(compose.foundation)
implementation(compose.material3)
}
}
val desktopMain by getting {
dependencies {
implementation(compose.desktop.currentOs)
}
}
}
}
UI代码写在commonMain中即可被所有平台使用。当某个功能依赖平台能力时，可以用expect/actual机制：在公共代码里声明expect，在各平台的actual中提供实现。例如文件路径处理，桌面端返回系统目录，Web端则返回浏览器存储相关信息。
二、桌面应用的入口配置与打包
桌面应用的入口非常直接，通过main函数启动一个Window。Compose Multiplatform在JVM上运行，因此可以直接调用Java生态的库，比如读写本地文件、调用串口、集成Swing组件等，这是桌面端相对Web端最大的优势。
fun main() = application {
Window(
onCloseRequest = ::exitApplication,
title = "我的桌面应用",
state = rememberWindowState(width = 1024.dp, height = 768.dp)
) {
App() // 共享模块中的UI入口
}
}
打包发布方面，官方推荐使用Compose Multiplatform的Gradle插件，它会下载匹配的JDK和所需依赖，把应用打包成各平台的独立发布包，例如Windows下的msi、macOS下的dmg。执行./gradlew packageDistributionForCurrentOS即可生成当前系统的安装包。需要注意打包机的架构要与目标平台一致，跨架构打包目前支持并不完善。
桌面端还有一些实用特性，比如系统托盘、全局快捷键、无边框窗口、多窗口管理等，这些都通过compose.desktop.window相关的API提供。内存占用方面，JVM应用的启动内存通常在一两百MB左右，如果对体积敏感，可以通过jlink裁剪JRE来减小分发包大小。
三、Web端接入：WASM与JS两种目标的选择
Web端目前有两种编译目标可选。一种是传统的Kotlin/JS，输出JavaScript代码；另一种是较新的Kotlin/WASM，输出WebAssembly字节码。从官方的演进方向看，WASM是未来主推的目标，运行性能更好，尤其在数值计算密集的场景下优势明显。新项目建议直接选择wasmJs目标。
配置好目标后，执行./gradlew :shared:wasmJsBrowserDevelopmentRun可以在本地启动开发服务器并自动打开浏览器预览。执行:shared:wasmJsBrowserDistribution则会生成可部署的静态资源，包括编译后的.wasm文件、JS胶水代码和index.html，把这些文件放到任意静态服务器上即可访问。
Web端有不少能力限制需要提前了解。浏览器没有本地文件系统的直接访问能力，网络请求只能使用fetch风格的API，且受同源策略约束。字体加载方式也不同，Web端需要在index.html或通过CSS引入字体，而不是像桌面端那样直接读取本地字体文件。此外，WASM目标的部分Kotlin库尚未完全适配，选择依赖时要确认其是否支持wasmJs。
四、常见问题与开发建议
开发中最常见的问题是平台API差异导致的编译报错。建议把所有平台差异封装到独立的expect/actual层，而不是在UI代码里到处写条件判断，这样公共UI层可以保持纯粹。依赖注入框架如Koin对多目标支持良好，配合KMP Observatory这类模板项目可以快速起步。
调试方面，桌面端可以直接用IntelliJ IDEA的断点调试；Web端则依赖浏览器开发者工具，WASM目标的调试体验在Chrome和Firefox中已经比较完善，可以查看Kotlin源码级的堆栈信息。性能调优时，注意避免在Composable函数中做耗时操作，remember和derivedStateOf的使用原则在所有平台上一致。
最后在版本管理上，Compose Multiplatform的版本与Kotlin版本强绑定，升级时需要同步调整Kotlin插件版本，建议参考官方的版本对照表操作，避免出现编译器与运行时不匹配的诡异问题。整体来看，桌面与Web共用一套代码的方案已经足够成熟，适合工具类应用、内部系统和管理后台这类场景优先落地。
Compose MultiplatformKotlin跨平台开发修改时间：2026-09-03 05:38:30