Kotlin Toolchain 0.13，JetBrains 推荐 KMP 都切换到到全新工具链

这套从 Amper 演进而来的 Kotlin Toolchain，从 0.13 开始，官方正式建议大部分新的 Kotlin Multiplatform 项目优先采用 Kotlin Toolchain ，用 project.yaml、module.yaml 声明项目和模块，统一执行环境准备、构建、测试、运行和发布。

比如以前 KMP 的痛点一般是 Android SDK、JDK、Xcode、模拟器、Gradle 插件和各平台配置需要团队分别维护，这里 Toolchain 开始把这些繁琐环节收进同一个构建入口，0.13 还补上了 Apple 依赖导入和 Native 迭代效率等关键支持。

一、KMP 构建终于有了更统一的入口

这次 0.13 主要增加了几个能力：

Swift Package Manager 依赖怎么进入 Kotlin/Native 编译链
Native 缓存省了哪部分编译
统一 CLI 和工程描述怎样让 AI Agent 更少试错

因为在传统的 KMP 项目里面，开发者经常要同时理解 Gradle、Android 工具链与 Xcode，遇到依赖或者 SDK 缺失的时候，还需要判断错误来自哪一层，但是现在 Toolchain 的思路比较直接：

用 YAML 描述目标平台、模块、依赖和构建选项，然后通过自身的任务执行和环境管理机制完成后面的步骤，而且开发团队也能把项目自带的 kotlin 包装脚本纳入版本控制，让开发机与 CI 采用约定好的 Toolchain 版本。

比如 0.13 的 kotlin new 就把项目类型和目标平台变成两个交互式选择，它和之前已经有的 kotlin init 用的同一套新初始化体验，区别在于 kotlin new 是这个版本的 CLI 增强引导：

这里支持选择 Compose Multiplatform、JVM、KMP Library、Ktor、Spring Boot 等模板，然后再配合 Android、iOS、Desktop、Web 和 Server 再按项目需要组合：

这个版本还修了一个体验问题，以前 Toolchain 在执行 kotlin build 或者 kotlin run 时能够自动准备 Android SDK，但是开发者先用 IDE 打开项目，SDK 缺失还是会导致同步失败，所以现在项目导入 IDE 时也能触发 SDK 自动配置，而且 iOS 方面还增加了 Xcode 初始化状态检查、Simulator Runtime 自动下载以及模拟器自动创建。

这里的工程收益很直接：新项目、CI 和不同开发机器使用统一的工程描述，环境准备过程也更加可预测。不过，这种便利并不代表 iOS 构建已经摆脱 macOS、Xcode 的要求。

另外 0.13 还加入了 Swift Package Manager 依赖支持，支持有 Apple 目标平台的模块直接声明 Swift Package，比如现在希望在 iOS App 的 Kotlin 代码里用 Firebase Analytics，可以配置：

yaml 复制代码

product: ios/app

dependencies:
  - swiftPackage:
      repository: "https://github.com/firebase/firebase-ios-sdk.git"
      version: "12.17.0"
      products: ["FirebaseAnalytics"]

之后可以在 Kotlin 代码中使用类似下面的导入：

arduino 复制代码

import swiftPMImport.app.FIRAnalytics
import swiftPMImport.app.FIRApp

在 SwiftPMImportTask.kt 的实现里面，其实就是 Toolchain 用生成的 SwiftPM/Xcode 工程调用 xcodebuild ，然后拿到实际构建参数，然后找到 Clang Module、提取链接选项，然后交给 Kotlin/Native 的 cinterop 生成可调用的绑定。

也就是原本需要开发者手动协调的 SwiftPM、Xcode、Clang 和 Kotlin/Native 构建步骤，现在统一集成到了一个构建链。

不过支持 SwiftPM 不是说 Kotlin/Native 就能直接调用任意纯 Swift API ，目前导入的还是 Objective-C 可见的接口：

swift 复制代码

// /path/to/CryptoKitWrapper/Sources/CryptoKitWrapper/CryptoKitWrapper.swift
// CryptoKit is a system library with Swift APIs that are not accessible to Objective-C
import CryptoKit
import Foundation

@objc public class CryptoKitWrapper: NSObject {
    @objc public static func sha256(data: NSData) -> NSString {
        return SHA256.hash(data: data).map { String(format: "%02x", $0) }.joined() as NSString
    }
}

另外发布链也同步完善了，比如你开发的是一个依赖 SwiftPM 的 KMP Library，发布时会带上 -swiftpm-metadata.json，这样消费端才能知道应该获取哪些 Swift Package，这个格式在这里沿用了 Kotlin Gradle Plugin 的相关约定，这部分增量主要都集中在 Toolchain 的依赖解析、cinterop、链接和发布集成上。

依赖本地 Swift Package 的 Library 只能发布到 mavenLocal，因为本地包的绝对路径不能在其他开发者机器上可靠复现，所以 Toolchain 会阻止发布到共享 Maven 仓库。

另外现在Native 缓存终于接进来了 ，做过 KMP iOS 开发的应该都有印象，有时只是改了共享模块中的一小段 Kotlin 代码，重新运行 iOS App 会需要等比较长的编译和链接过程，这个也是 Shopify 从 RN 转原生的时候，提了为什么不选 KMP 的原因之一。

因为 Kotlin/Native 编译存在不同阶段，项目代码会先生成 .klib，然后编译器还要把代码和依赖处理成最终 Native 二进制，传统情况下，后一个阶段会反复处理大量已经没有变化的依赖。

然后 0.13 通过 KTC-5422 把 Kotlin/Native 已有的 Compiler Caches 接入到了 Toolchain 构建流程，比如源码 NativeCompilerCaches.kt 里面可以看到几个关键参数：

ini 复制代码

-Xauto-cache-from=...
-Xenable-incremental-compilation
-Xic-cache-dir=...

这里分成两类缓存：

外部依赖可以编译成可跨构建、跨项目复用的机器级缓存
项目自己的代码用每文件级增量缓存

配合 NativeLinkTask.kt 保留和重用缓存目录，下一次只修改一个 Kotlin 文件的时候，Native 链接阶段有机会复用大部分已有结果。

这套设计继承了 Kotlin/Native 已经有的编译器缓存机制，属于 Toolchain 这次真正完成的工程接入。

最后 JetBrains 还把 Kotlin Toolchain 和 AI Agent 结合起来，提供了官方的 Kotlin Agent Skills，可以告诉 Agent 怎么识别 Toolchain 工程、使用正确的 CLI、生成模块配置，还有避开已有 Gradle 项目。

在官方的一组测试里面，JetBrains 让 Claude Sonnet 5 用 Claude Code 创建同时支持 Android、iOS 的 Kotlin Toolchain 工程，每组运行十次，两组环境和任务相同，区别在于有没有 Toolchain Skill ：

指标	无 Skill	有 Skill
平均 Reward	0.6333	1.0000
平均工具调用	29	9
平均总 Token	976,117	405,176
平均端到端时间	15分21秒	15分30秒

整体Token 消耗下降 58%，工具调用也明显减少。

所以后面，KMP 大概率基本都是一个 kotlin 命令，Gradle 是真的退役了。