告别 KMP 选型地狱！klibs.io 上线，全平台库一键筛选太省心

KMP 项目最容易卡住的地方，不是写 expect/actual。而是选库：网络、存储、依赖注入、UI、日期时间、加密，每个库都要确认支持哪些平台，版本是不是还在维护，能不能进 commonMain。

JetBrains 做了一个专门找 Kotlin Multiplatform 库的网站：klibs.io。

解决选库问题

你可以按关键字搜索库，也可以按平台过滤结果，比如 Android、iOS、JVM、JavaScript、WASM。对多端项目来说，这比只看 README 省很多时间。

官网地址是：

bash 复制代码

https://klibs.io

一个典型场景是：你正在做一个 Android + iOS 的 KMP App，需要在 commonMain 里放网络层。

以前的流程通常是这样：

bash 复制代码

搜索 Kotlin HTTP client
打开 GitHub
看 README
翻 Gradle 配置
确认有没有 iosArm64 / iosSimulatorArm64
再看 Maven Central 版本
最后才敢加依赖

klibs.io 把这里面最耗时的部分提到了搜索结果页：这个库支持哪些平台、有哪些版本、仓库活跃度如何，都可以先扫一遍。

平台支持

KMP 选库和普通 Android 选库最大的区别是："能不能编译"不是implementation 能决定的。

一个库支持 JVM，不代表支持 Android；支持 Android，也不代表支持 iOS；支持 iOS，还要看它有没有对应的 Kotlin/Native target。

在 Gradle 里，KMP 项目最后会落到 source set 上：

bash 复制代码

kotlin {
    androidTarget()
    iosArm64()
    iosSimulatorArm64()

    sourceSets {
        commonMain.dependencies {
            implementation("io.ktor:ktor-client-core:3.0.0")
        }
    }
}

如果这个依赖没有发布 iOS 目标，问题不会等到运行时才出现，Sync 或编译阶段就会报错。

所以搜索 KMP 库时，第一眼应该看平台矩阵，而不是 star 数。

klibs.io 的价值就在这里：它把平台维度摆在搜索流程里。你要找 Android + iOS 能共用的库，就先按这两个平台筛掉不合适的结果。

用例比分类更重要

KMP 库不是越多越好。

真正写项目时，开发者通常不是在找"一个库"，而是在找"这个能力有没有成熟的多平台实现"。

比如网络层，可以先看这些方向：

bash 复制代码

commonMain.dependencies {
    implementation("io.ktor:ktor-client-core:<version>")
    implementation("io.ktor:ktor-client-content-negotiation:<version>")
    implementation("io.ktor:ktor-serialization-kotlinx-json:<version>")
}

Android 和 iOS 再分别放平台 engine：

bash 复制代码

androidMain.dependencies {
    implementation("io.ktor:ktor-client-okhttp:<version>")
}

iosMain.dependencies {
    implementation("io.ktor:ktor-client-darwin:<version>")
}

这类库适合放在 KMP 的共享层，因为请求模型、序列化、错误处理、Repository 都可以跨平台复用。

存储层要更谨慎。你需要确认它解决的是 key-value、数据库、文件系统，还是安全存储。不同能力背后的平台差异很大，iOS Keychain、Android Keystore、SQLite、文件路径都不是一个抽象能全部吃掉。

依赖注入也是一样。KMP 项目里常见做法是把接口、Repository、UseCase 放到 commonMain，再在平台层接入具体生命周期。

bash 复制代码

interface UserRepository {
    suspend fun loadUser(): User
}

class GetUserUseCase(
    private val repository: UserRepository
) {
    suspend operator fun invoke(): User = repository.loadUser()
}

这段代码本身不依赖平台。真正要看的，是 DI 库能不能在 Android、iOS、Desktop 这些目标上稳定初始化，能不能和 Compose Multiplatform 或原生入口配合。

别只看能不能用

一个 KMP 库能搜到，不等于适合进生产项目。

主要看以下四个信息：

第一是平台覆盖。你的项目目标是什么，就看它有没有对应 artifact。Android + iOS 是最常见组合；如果还要 Desktop、Web、WASM，就不能只看移动端。

第二是版本节奏。KMP 生态变化比较快，Kotlin、Compose Multiplatform、Kotlin/Native、Gradle 插件都会影响库的可用性。长期不发版的库，不一定不能用，但要降低预期。

第三是依赖链。很多库表面是 multiplatform，底层可能依赖一个平台能力。网络、数据库、加密、图片加载、日志这些方向尤其要看清楚。

第四是 API 边界。共享层的代码应该稳定，不要把平台生命周期、Activity、UIViewController 之类对象扩散到 commonMain。

比较理想的结构是这样：

bash 复制代码

shared/
  commonMain/
    data/
    domain/
    presentation/

  androidMain/
    platform/

  iosMain/
    platform/

选库时可以反过来问一句：这个库是让 commonMain 更干净，还是把平台细节塞进了共享层？

搜索结果只是第一步

klibs.io 可以帮你更快缩小范围，但最后还是要回到工程里验证。

最小验证不是写 demo 页面，而是建一个小的依赖试验。

bash 复制代码

kotlin {
    androidTarget()
    iosArm64()
    iosSimulatorArm64()

    sourceSets {
        commonMain.dependencies {
            implementation("group:name:<version>")
        }
    }
}

然后至少跑这几个任务：

bash 复制代码

./gradlew :shared:compileKotlinAndroid
./gradlew :shared:compileKotlinIosArm64
./gradlew :shared:compileKotlinIosSimulatorArm64

能编译只是底线。网络、数据库、加密这类库，还要在真机或模拟器上跑一次最小调用，因为有些问题来自平台权限、线程模型、Native 链接或系统 API 差异。

UI 库更要实际看效果。Compose Multiplatform 里，一个组件在 Desktop 看起来正常，不代表 iOS 手势、键盘、滚动、弹窗都符合预期。

对 KMP 生态的意义

KMP 这几年最大的问题之一，是生态信息分散。

库在 Maven Central，代码在 GitHub，文档在 README，平台支持藏在 Gradle metadata 或发布配置里。新项目做技术选型时，很容易在同一类库之间来回横跳。

klibs.io 把"发现"和"初筛"这一步做成了专门服务。

这对 KMP 生态有两个实际影响。

一个是降低新项目试水成本。团队不需要先把所有候选库拉下来编一遍，至少可以先按平台和用例排除一批。

另一个是倒逼库作者把平台支持讲清楚。KMP 库不再只靠 README 里的几句描述来证明自己，平台矩阵、版本、仓库信息都会被放到同一个搜索体验里比较。

对 Android 开发者来说，KMP 选型会越来越接近日常 Android 选库，但多一个平台维度。

以前问的是：

bash 复制代码

这个库好不好用？

现在要先问：

bash 复制代码

这个库能不能在我的目标平台一起用？

最后

klibs.io 你用过了吗？

#Kotlin #KMP #ComposeMultiplatform #Android开发