1. Gradle 版本兼容概述

说到 Gradle 版本兼容，我自己的第一反应就是：「这玩意儿到底能不能平滑升级？」 我见过太多团队，因为 Gradle 版本不匹配，构建直接挂掉，一查就是半天。说白了，版本兼容这件事，决定了你项目的「构建稳定性」。你想想看，如果今天你升了个 Gradle 小版本，第二天 CI 全红了，那多难受。

1.1 为什么需要关注版本兼容

Gradle 是一个快速迭代的构建工具。每个版本都可能引入新特性、修复 Bug，但同时也可能修改内部 API 或默认行为。举个例子：

• 插件生态：你的 Android 插件、Kotlin 插件等，都有自己支持 Gradle 的版本范围。如果 Gradle 版本太新，插件还没适配，就会报错。
• 构建脚本本身：Gradle API 中的某些类、方法可能在主版本中被标记为 deprecated，然后在后续版本中删除。
• 构建性能与特性：新版 Gradle 可能会优化增量编译、缓存策略，但你如果用旧版插件，反倒可能冲突。

我曾在项目中遇到过，把 Gradle 从 6.8 直接升到 7.0，结果发现某个自定义 Task 里用到的 Project.afterEvaluate 行为变了，导致依赖解析顺序出错。排查了整整一天……嗯，从那以后我再也不敢无脑升版本了。

1.2 Gradle 版本号规则

Gradle 使用 语义化版本号（SemVer）的方式命名，但做了自己的微调。格式如下：

主版本.次版本.补丁版本（-里程碑-快照？）
示例：6.8.3、7.0.2、7.1-rc-1、7.2-SNAPSHOT

我把它的规则拆解一下：

1.3 向前与向后兼容的定义

这两个术语经常听到，但很多人容易搞混。我直接用大白话说：

• 向后兼容 (Backward Compatible)：新版本的 Gradle 能运行旧版本编写的构建脚本、旧插件。说白了，你升了 Gradle 版本，你的代码不用改就能跑。大部分次版本和补丁版本都是向后兼容的。
• 向前兼容 (Forward Compatible)：旧版本的 Gradle 能运行新版本格式的脚本。这个比较少见，因为新版本可能引入了新语法、新 API，旧版本识别不了。

举个例子：

// 假设 Gradle 6.8 支持这种写法
tasks.register('myTask') { 
    doLast { println 'hello' }
}

// Gradle 7.0 开始废弃了另一种写法，但注册方式仍然兼容。
// 如果你在 Gradle 6.8 里使用了 Gradle 7.0 才有的 API（比如新版 Kotlin DSL 特性），
// 那就属于「向前兼容失败」。

我记得有一次，项目用了 Gradle 6.8 的 kotlin-dsl 插件，但脚本中写了一个只在 7.0 才支持的 listOf 隐式导入。结果 CI 编译报错，因为 6.8 的 Gradle 不认识那个符号。这就是典型的「向前兼容」问题——你依赖了新版本特性，但运行环境是旧版本。

1.4 本章知识体系总览

1.5 小结

这一章我们聊了版本兼容为什么重要——说白了就是避免构建突然爆炸。Gradle 的版本号规则决定了兼容性风险等级，主版本要谨慎，次版本和补丁相对安全。向前/向后兼容的定义帮你判断：升级后你的脚本是否还能跑？旧环境能否跑新脚本？