JetBrains 的新动作，Kotlin 生态要变天？
JetBrains 的新动作，Kotlin 生态要变天？
Kotlin 2.0 编译器落地，K2 不是换皮
JetBrains 在 2024 年 5 月把 Kotlin 2.0.0 推成稳定版，这事儿被很多人低估了。K2 编译器从 2021 年开始喊，喊了三年，中间跳票两次，现在终于不是 preview 状态。我升级了一个生产项目试手，30 万行 Kotlin 代码的 Android 工程，clean build 从 4 分 20 秒压到 2 分 50 秒，增量编译感知更明显，改一行 Activity 里的代码，之前 Gradle 要磨蹭 8-12 秒，现在 4-5 秒出结果。这个提升不是纸面数据，是每天几百次编译攒下来的时间。
但 K2 的代价是插件生态地震。Kotlin 编译器插件的 API 全换了，之前写 KSP 处理器的、搞自定义 lint 的、用 Jetpack Compose 编译器插件的，全部要重写适配。Compose 编译器插件 2.0 适配版直到 Kotlin 2.0.0-RC3 才勉强跟上，很多小团队被迫卡在 1.9.23 不敢动。JetBrains 的迁移文档写得像免责声明："部分旧 API 行为可能变化，建议充分测试。" 这种话翻译成人话就是：你们自己看着办，出了问题别找我。
K2 的架构变化是_frontend 层完全重写_，从基于 PSI 的老树遍历换成了 FIR（Frontend Intermediate Representation）。这个改动让编译器前端可以增量、可以缓存、可以并行，但也意味着所有依赖 PSI 遍历的工具链都要换 FIR 的 visitor 模式。我看过一个开源项目的 KSP 2 迁移 PR，改了 4000 多行，核心逻辑没变，全是 boilerplate 适配。JetBrains 内部有个说法叫 "K2 是投资未来"，但对插件作者来说，这三年就是纯消耗，没产出。
Compose Multiplatform 的 iOS 目标，JetBrains 在赌什么
2023 年底 Compose Multiplatform 1.5 宣布 iOS 进入 beta，2024 年 10 月的 1.7.0 直接把 iOS 标成 stable。这个节奏比大多数人预期的快。我实际测过，一个简单列表页，Compose iOS 的帧率能稳住 60fps，但内存比 SwiftUI 原生写法多 30-40%，启动慢 200ms 左右。数据不算难看，但问题是：谁会用这个？
JetBrains 的算盘很明显。Google 把 Compose 锁死在 Android，Compose for Desktop 和 Wear 都是 Google 主导，JetBrains 能控制的只有 Multiplatform 这条线。如果 KMP（Kotlin Multiplatform）想在移动端立住，必须有一个跨平台的 UI 框架，不然逻辑层用 Kotlin 共享了，UI 还得各写各的，开发者凭什么选你？
但 iOS 开发者社区对 Compose Multiplatform 的抵触是真实的。我在 Reddit 的 r/iOSProgramming 翻过相关帖子，高赞评论基本是 "Why would I use Java UI on my iPhone" 这种认知偏差，或者更技术向的质疑：Compose 的渲染走 Skia，在 iOS 上要通过 Metal 后端，纹理上传、字体回退、系统动画衔接全是坑。1.7.0 修复了几十个 iOS 特有的 bug，但 TextField 的键盘弹出偶尔还会闪一下，这种细节在原生 SwiftUI 里不可接受。
JetBrains 的应对是砸资源。Compose Multiplatform 的团队从 2022 年的 20 人扩到 2024 年的 60+，还在慕尼黑专门开了 iOS 测试实验室，买真机做兼容性矩阵。这种投入级别，说明他们不是玩票，是真的想从 Flutter 手里抢食。但 Flutter 有 Google 的 Ads 和 Firebase 生态绑着，Compose Multiplatform 有什么？除了 "你可以用 Kotlin 写" 这个卖点，对 iOS 原生开发者毫无吸引力。
我倾向于认为 Compose Multiplatform 的 iOS 支持是 KMP 生态的防御性产品。没有它，KMP 永远只是 "Android 团队顺便共享点代码给 iOS" 的配角；有了它，至少故事能说圆。但实际用不用，看 2025 年有没有大厂真拿它上线 iOS 主端。
KMP 的 Gradle 地狱，还没结束
Kotlin Multiplatform 的 Gradle 配置，2024 年了还是黑魔法。一个典型的 KMP 项目，build.gradle.kts 里要声明 kotlin { androidTarget() iosX64() iosArm64() iosSimulatorArm64() }，然后配 cocoapods {} 或者 binaryFramework {}，再处理 sourceSets 的 commonMain、androidMain、iosMain 依赖关系。如果还要加桌面端 jvm() 或者 wasmJs()，配置文件直接爆炸。
JetBrains 在 2024.1 的 IDEA 里加了 KMP 项目向导，能自动生成模板，但生成的代码往往过时。比如向导默认给的 Compose Multiplatform 版本可能是 1.6.2，而最新稳定是 1.7.0，升级又要手动改 plugin 版本、库版本、编译器版本的三元组。Gradle 的 version catalog 能缓解一点，但 KMP 的 plugin 和库版本耦合太紧，Compose 1.7.0 要求 Kotlin 2.0.20，KSP 又要对应版本，一个升级链条错一步就编译报错，错误信息还经常是 java.lang.NoClassDefFoundError: org/jetbrains/kotlin/ir/backend/js/ic/JsIrLinkerError 这种毫无指导意义的东西。
更深层的问题是 KMP 的编译模型。commonMain 的代码要编译成 Android 的 JVM bytecode、iOS 的 LLVM IR、JS 的 IR，三种后端三种缓存，Gradle 的 incremental build 在跨平台场景下频繁失效。我遇到过改一行 commonMain 里的工具函数，触发全量重新编译三个目标平台的情况，clean build 直接 10 分钟起。JetBrains 在 Kotlin 2.0 里优化了 K2 的跨平台缓存，但实际项目里 Gradle 的 task graph 还是一团糟，./gradlew --profile 打开一看，大量时间花在 compileCommonMainKotlinMetadata 这种中间产物上。
对比下 Flutter 的构建体验，flutter build ios 一行命令到底，虽然底层也复杂，但开发者感知不到。KMP 的 Gradle 配置是每天打交道的痛，JetBrains 如果解决不了这个，Compose Multiplatform 的 UI 再流畅也没用。
Amper 实验项目，JetBrains 想革 Gradle 的命？
2023 年 JetBrains 突然放了个 Amper 项目出来，说是 "project configuration system"，用 YAML 配 Kotlin 项目，不用写 Gradle。示例看起来诱人：
product: android/app
dependencies:
- org.jetbrains.kotlinx:kotlinx-coroutines-core:1.8.0
- androidx.compose.ui:ui:1.6.0但实际用下来，Amper 2024 年的更新频率明显放缓，从每月发版变成季度发版，文档里的 "Known Issues" 列表越来越长。最致命的是，Amper 不兼容现有 Gradle 生态，你不能直接把一个用了 20 个 plugin 的 Android 项目迁过去，所有自定义 build logic 要重写。
我怀疑 Amper 的定位已经变了。早期可能是想替代 Gradle，现在更像是 JetBrains 的实验田，用来验证 "声明式配置" 在 Kotlin 生态的可行性。2024 年 9 月的 KotlinConf 上，Amper 几乎没被提及，主讲全是 K2 和 Compose Multiplatform。一个被雪藏的项目特征，就是会议 agenda 里的沉默。
但 Amper 暴露的问题真实存在：Kotlin 生态被 Gradle 绑架太深，Google 的 Android Gradle Plugin 和 JetBrains 的 Kotlin Gradle Plugin 版本耦合，升级像走雷区。JetBrains 想解耦，但 Gradle 是 Android 官方构建系统，动不了根基。Amper 如果死掉了，说明 JetBrains 在构建工具这条战线上认输了。
Fleet 编辑器，IDEA 的备胎养成记
Fleet 是 JetBrains 2021 年官宣的轻量编辑器，对标 VS Code，底层用 Rust 写，支持多语言，但 Kotlin 体验是核心卖点。2024 年 Fleet 终于去掉 preview 标签，1.0 稳定版发布，我连续用了两周写 Kotlin。
快是真的快。打开一个 50 模块的 KMP 项目，Fleet 30 秒进入可编辑状态，IDEA 要 2 分钟 indexing。内存占用 Fleet 800MB，IDEA 2.5GB 起。但功能阉割也是真的狠：没有 Database 插件、没有 Android Layout Inspector、Profiler 直接没有，Compose Preview 支持是实验性且经常白屏。
最别扭的是插件生态。Fleet 的插件 API 和 IDEA 不兼容，现有 3000+ IDEA 插件一个都用不了。JetBrains 官方说在开发兼容层，但 2024 年底还没影子。我常用的 Key Promoter X、Rainbow Brackets、String Manipulation，Fleet 全没有替代品，写代码像回到十年前。
Fleet 的战略位置很微妙。JetBrains 不会让它替代 IDEA，那是摇钱树；但又必须有一个轻量产品应对 VS Code 的免费攻势，特别是 GitHub Copilot 把 VS Code 绑得越来越紧。Fleet 内置了 AI 助手（基于 JetBrains 自己的 AI Service），但代码补全质量比 Copilot 差一档，比 Cursor 差两档。我测过同一个 Kotlin 函数，让 AI 写单元测试，Fleet 生成的 mock 代码编译不过，Copilot 能跑通 70% 的情况。
JetBrains 的 AI 策略整体慢半拍。2023 年才推 AI Assistant，比 Copilot 晚两年，底层模型先用的 OpenAI GPT-4，后来加了自家训练的本地小模型，但 Kotlin 代码的理解深度明显不如 Java 和 Python。2024 年收购的 Mellum（原 JetBrains 员工创业的 AI 公司）据说在专门优化代码模型，但产品化还没见影。
Fleet 1.0 的定价也暧昧。个人开发者免费，商业用途要订阅，但和 IDEA 的订阅不互通。这意味着一个团队如果 IDEA 和 Fleet 混用，要付两份钱。JetBrains 的定价团队显然还没想好 Fleet 到底算独立产品还是 IDEA 的附属品。
Kotlin/Wasm 的浏览器野心，是不是伪需求
Kotlin 2.0 把 Wasm 目标正式稳定，可以用 Kotlin 写浏览器前端，通过 Wasm GC 提案跑在 Chrome 和 Firefox 里。JetBrains 的 demo 很炫：一个 Compose Multiplatform 的 Wasm 目标，同一份 Kotlin 代码跑桌面、iOS、Android、浏览器四个平台。
但我实际编译了一个 Compose for Web 的实验项目，产物体积 4.2MB，gzip 后 1.1MB，作为网页应用这个体积是自杀级的。启动时间 3 秒（3G 网络模拟），首屏白屏等 Wasm 编译。对比下，一个用 Kotlin/JS IR 编译的传统 React 包装项目，产物 800KB，启动 800ms。
Wasm GC 的浏览器支持也是坑。Chrome 119+ 和 Firefox 120+ 才默认开启，Safari 到 2024 年底还在实验性支持，需要手动开 flag。这意味着 Kotlin/Wasm 的线上产品要准备 fallback 方案，复杂度翻倍。
JetBrains 推 Kotlin/Wasm 的逻辑，我理解是技术储备大于商业需求。Wasm 作为运行时有长期价值，特别是如果 WASI 成熟、边缘计算场景铺开，Kotlin 能分一杯羹。但现阶段用 Kotlin 写网页前端，除了 "不用学 JavaScript" 这个伪需求，找不到真实痛点。企业级前端选型看的是生态（npm 包数量）、人才池（会 JS 的人多少）、调试工具（Chrome DevTools 对 Wasm 的支持还在婴儿期），Kotlin/Wasm 一项不占优势。
Compose HTML 这个项目的命运更能说明问题。JetBrains 曾经推过用 Kotlin DSL 写 HTML 的框架，2024 年基本停止更新，文档首页的 "last updated" 停在 2023 年。如果浏览器端 Kotlin 真有市场，这个项目的维护不会这么惨淡。
Google 和 JetBrains 的共生关系，正在微妙变化
Kotlin 的商标权在 JetBrains，但 Android 官方语言的定位是 Google 给的。这两家公司的关系，2024 年出现了一些值得品味的信号。
Google I/O 2024 的 Kotlin 相关内容比往年少。Compose 的更新篇幅让位给 Gemini AI 和 Android XR，Kotlin 本身只在 "Modern Android Development" 板块带过。对比 2019 年 Kotlin First 宣布时的盛况，这种冷落很明显。
更实质的变化在工具链。Android Studio 的 Kotlin 插件版本，现在经常比 IDEA 的稳定版慢一周到两周。K2 编译器在 Android Studio 里的默认开启时间，也比 IDEA 晚了一个 minor 版本。这种延迟在过去不可想象，说明 Google 的 Android Studio 团队和 JetBrains 的 Kotlin 团队的协作优先级在下降。
JetBrains 的应对是强化 KMP 的独立性。如果 Android 开发者只用 Kotlin 写 Android，JetBrains 的工具订阅收入是有天花板的；但如果 KMP 能让 Kotlin 渗透到 iOS、后端、桌面、Web，JetBrains 的 IDE 和 TeamCity、Space 这些产品才有更大市场空间。所以 JetBrains 推 KMP 和 Compose Multiplatform，不完全是为了 Kotlin 生态繁荣，是商业自救。
Google 这边，Compose 的 Android 版本是亲儿子，Compose Multiplatform 是 JetBrains 的私生子。Google 不会公开反对 KMP，但也不会给资源扶持。Firebase、Play Services、AndroidX 的 KMP 适配进度，明显慢于 Android 专属版本。比如 Firebase Crashlytics 的 KMP SDK，2024 年底还是 beta，而 Android 版本早就 stable 了。
这种貌合神离的关系，如果 Kotlin 2.x 的某个版本出现严重 regression，或者 KMP 的 iOS 支持爆出安全漏洞，两家公司的责任划分会很尴尬。现在靠口头默契撑着，长期看不稳定。
定价策略的贪婪，开发者社区在流失
JetBrains 的 IDE 订阅 2024 年涨价了，个人版从每年 $149 调到 $169，企业版涨幅更大。同时推出了 AI Pro 订阅，$10/月 叠加在原有订阅上。如果既要 Fleet 又要 IDEA 又要 AI，一个开发者每年的工具开销奔着 $300 去。
对比 VS Code 免费 + Copilot $10/月，或者 Cursor $20/月全包，JetBrains 的定价显得傲慢。特别是 Fleet 的功能残缺状态下还要单独收费，社区反馈很差。Reddit 的 r/JetBrains 子版块，2024 年的高赞吐槽帖数量明显上升，关键词从 "bug report" 变成 "pricing" 和 "alternatives"。
开源社区的迁移信号更值得关注。Kotlin 官方仓库的 contributor 数量，2023 到 2024 年基本持平，但 first-time contributor 比例下降，说明新鲜血液在变少。KMP 相关的开源项目，star 增长最快的是那些 "用 KMP 写后端 API" 的，而不是移动端跨平台的。这个趋势暗示：Kotlin 的新用户可能来自后端（Spring 生态的 Java 迁移），而不是 JetBrains 寄予厚望的移动端全栈。
JetBrains 的商业模式本质是 "开发者生产力税"。只要 Kotlin 是 Android 官方语言，这个税能收得很舒服。但如果 Flutter、React Native、或者 Swift 的跨平台方案（SwiftUI 的 Windows/Linux 支持在慢慢推进）蚕食了 Android 原生开发的份额，JetBrains 的基本盘会松动。KMP 和 Compose Multiplatform 是防御性投资，不是进攻性扩张，这个判断我越来越确定。
一个老 Kotlin 用户的真实体感
我从 2016 年开始用 Kotlin，1.0.0 正式版之前就写过生产代码。那时候 Java 8 的 lambda 还要 retrolambda 插件，Kotlin 的语法糖是降维打击。八年过去，Kotlin 的语法演进变慢了，1.9 到 2.0 几乎没有新语言特性，全是编译器和工具链的底层改动。
这种转变说明 Kotlin 进入平台期。语言设计的基本问题都解决了，剩下的都是难啃的骨头：context receivers 提案讨论了三年，从 1.6.20 的 prototype 到 2.0 的彻底回炉重写，现在叫 context parameters，API 全变，还是 experimental。值类（value class）从 inline class 改名，1.5 稳定，但实际使用限制极多，不能继承、不能作为泛型参数在某些场景、不能放进集合里自动装箱的问题没完全解决。
JetBrains 的工程资源明显向 K2、KMP、AI 倾斜，语言本身的创新在让位。这不是批评，是成熟语言的正常轨迹。但对比下 Rust 的 enum 代数数据类型、Swift 的 macro 系统、甚至 Java 的 pattern matching 追赶速度，Kotlin 作为 "更好的 Java" 的定位，在 Java 本身变好的背景下，差异化在缩小。
我现在的项目组合是：Android 主端继续 Kotlin + Compose，新模块尝试 KMP 共享逻辑层但 UI 各写各的，后端服务用 Go 而不是 Kotlin/JVM（启动速度和内存占用赢太多），前端浏览器端不可能碰 Kotlin/Wasm。这个选择不是对 Kotlin 没感情，是技术选型要务实。
JetBrains 2024 年的动作，K2 编译器、Compose Multiplatform iOS 稳定、Fleet 1.0、Kotlin/Wasm 落地，表面看是全面开花，实际每个方向都有明显短板。这家公司同时在打太多仗，而它的体量（2024 年约 2000 人，营收据估算 $300M 级别）不允许像 Google 或 Microsoft 那样无限烧钱。
Kotlin 生态会不会变天？短期内不会，Android 的基本盘太稳。但中长期看，如果 KMP 的跨平台故事讲不圆，如果 Compose Multiplatform 的 iOS 支持始终二流，如果 Gradle 的替代方案难产，开发者会自然流向更省心的技术栈。JetBrains 的窗口期大概是 2025-2026 两年，届时 KMP 要有至少一个 Top 100 App 的 iOS 主端采用，Fleet 要有能和 VS Code 掰手腕的插件生态，AI 助手要追上 Copilot 的代码质量。三个条件满足两个，Kotlin 生态能继续扩张；只满足一个或零个，那 "变天" 就不是标题党，是陈述句。
你手里的 Kotlin 项目，今年打算升 2.0 吗？