路科上周碰到一个挺典型的求助：对方把网上抄来的构建脚本贴进项目，一段是 Groovy 的 implementation 'xxx'，一段是 Kotlin DSL 的 implementation("xxx")，编译结果时好时坏。很多人分不清 Gradle 里 Groovy DSL 和 Kotlin DSL 其实对应着两套不同的构建脚本语言，语法、报错方式、迁移成本都差很多。这篇文章就把它们放在一起做一次完整的对比，给正在选型或准备迁移的团队一个可以落地的参考。
单看标题里的“Groovy/Kotlin DSL对比”，有不少读者会以为这是个简单的语法偏好问题，实际接触下来你会发现，它牵扯到构建脚本的可维护性、IDE辅助能力、团队技能栈、插件兼容性，甚至构建性能。下面我会从两套 DSL 的由来开始，逐步拆到具体代码差异，再结合个人踩坑经验给出选型建议。
1. 同一个 Gradle，两套 DSL 的历史原因：这问题不是今天才有
1.1 从 XML 到脚本语言，Gradle 当初为什么选 Groovy
在 Gradle 出现之前，最主流的构建工具是 Ant 和 Maven。Ant 的构建文件是 XML，写起来冗长，逻辑稍微复杂一点就要靠一堆自定义任务；Maven 虽然引入了约定优于配置，但想在 pom.xml 里表达条件判断、循环、动态拼接版本号，依然非常痛苦，因为 XML 本质上只适合描述静态结构，不适合表达流程。
Gradle 的突破口就是“把构建脚本当成程序来写”。它默认选了 Groovy：这门语言和 Java 兼容，语法又比 Java 灵活得多，闭包、动态属性、字符串插值这些特性非常适合做外部 DSL。你可以在脚本里写循环、写函数、甚至临时定义一个类，而不需要为此切到另一种语言。也正因如此，Gradle 很快就和 Maven XML 拉开了体验差距。
但 Groovy 的优势同时也是它的隐患。动态语言对 IDE 不友好，属性拼错了、方法名写错了，往往要到配置阶段甚至执行阶段才会暴露。项目一大，构建脚本复杂起来，这种“运行期才报错”的体验会让人非常难受。
1.2 Kotlin 成熟后，Gradle 官方顺势推出第二套 DSL
Kotlin 在 Android 生态里普及之后，大量开发者开始希望“能用 Kotlin 的地方都