导语： 在 Kotlin 生态持续演进的浪潮中，JetBrains 日前宣布将 Amper 正式纳入 Kotlin Toolchain 核心组件，这一“转正”动作不仅标志着项目本身走向成熟，更在构建工具领域投下了一枚重磅炸弹。当新一代声明式构建方案 Amper 获得官方背书，业界不禁追问：长期作为 Kotlin 默认构建系统的 Gradle，是否正面临出局风险？
“转正”背后：Amper 的野心与定位
Amper 自2023年以实验性项目问世以来，始终以“简化多平台构建”为核心使命。它摒弃了 Gradle 繁复的 Groovy 或 Kotlin DSL 脚本，转而采用纯 YAML 配置文件，开发者只需声明“需要什么平台、依赖什么库”，Amper 便能自动推导出完整的构建逻辑。这种“声明式”设计大幅降低了学习成本，尤其对跨平台项目（如同时支持 Android、iOS、WebAssembly）的开发者极具吸引力。
此次“转正”意味着 Amper 将正式进入 Kotlin 的官方技术栈，与 Kotlin 编译器、标准库、KSP 等组件平级。JetBrains 在公告中强调，Amper 将被集成到 IntelliJ IDEA 和 Fleet 等 IDE 中，提供零配置的开箱体验。同时，官方将投入更多资源优化其性能与兼容性，并计划在未来的 Kotlin 版本中默认捆绑 Amper CLI。
Gradle 何以“失宠”？—— 慢、繁、耦合
Gradle 作为 Android 和 Kotlin 生态的长期“标配”，其核心缺陷早已被开发者诟病。首先是构建速度：即使启用 Gradle 守护进程和缓存，大型项目的首次构建仍动辄数分钟，增量编译的稳定性也常因插件冲突而大打折扣。其次是配置复杂性：一个标准的 Android 模块 build.gradle.kts 可能包含数十行 DSL，涉及签名、混淆、资源限定符、多维度变体等，初学者极易迷失在脚本中。更致命的是插件耦合：Gradle 的能力高度依赖插件生态，而插件间的版本兼容、API 变更频繁导致项目迁移成本极高。
Amper 则试图用“约定优于配置”的思路解决这些痛点。例如，它内置了对 Kotlin Multiplatform、Jetpack Compose、Ktor 等框架的智能感知，开发者无需手动声明任务依赖或资源路径。这种激进简化，本质上是在挑战 Gradle 的“万能工具箱”定位。
Gradle 的“反击”与现实困境
面对 Amper 的步步紧逼，Gradle 团队并非无动于衷。去年发布的 Gradle 8.7 引入了“声明式配置文件”（Declarative Configuration）的实验特性，允许用户用类似 YAML 的格式定义部分构建参数。然而，这一方案始终停留在“补丁”层面——它仍需要在 DSL 中混用，且无法触及 Gradle 底层任务图生成和执行引擎的冗余。
更关键的是，Gradle 的市值与商业模式高度依赖企业客户。Android 官方构建系统的身份为其带来了巨大的流量，但如果 JetBrains 选择在 Kotlin First 的生态中主推 Amper，Gradle 可能逐渐被边缘化为“仅适用于 Java/Android 兼容场景”的工具。毕竟，Kotlin 多平台项目如今已占新项目启动的相当比例，而 Amper 在这一领域的体验明显更优。
未来走向：共存而非取代？
综合各方信息，短期内 Gradle 不会被完全替代。对于已有数万行 Gradle 脚本的大型项目，迁移成本近乎不可承受。Amper 的定位更可能是“新生代项目首选”以及“Kotlin 多平台项目的官方推荐方案”。JetBrains 也表示会继续维护 Kotlin Gradle 插件，保证兼容性，但未来的创新资源会向 Amper 倾斜。
有趣的是，Amper 本身也保留了与 Gradle 的互操作能力——它可以通过“桥梁”机制调用现有 Gradle 任务。这意味着 Amper 的最终目标不是掀翻桌子，而是提供一条更为现代的选型路径。对于开发者而言，现在或许是最好的学习时机：一面守住 Gradle 的存量经验，一面拥抱 Amper 的声明式未来。
结语： Amper 的转正不是一个终点，而是 Kotlin 构建工具生态分化的起点。Gradle 的故事尚未完结，但其主角光环正在褪去。当“声明式”成为行业共识，谁能为开发者省下更多时间，谁就能赢得下一个十年。