本文详解在jcenter停用后如何正确配置gson依赖，同时介绍更推荐的现代替代方案（如moshi、kotlinx serialization），涵盖gradle配置、版本兼容性及最佳实践。
本文详解在jcenter停用后如何正确配置gson依赖，同时介绍更推荐的现代替代方案（如moshi、kotlinx serialization），涵盖gradle配置、版本兼容性及最佳实践。
随着JCenter仓库于2021年2月正式停用并进入只读状态，大量旧项目在构建时出现 Cannot resolve symbol Gson 等依赖解析失败问题。这并非Gson本身被弃用，而是其传统分发渠道失效所致。幸运的是，Gson已全面迁移至 Maven Central，且持续维护（最新稳定版为 2.10.1）。以下是完整、可靠的接入方案：
✅ 正确配置 Gson（推荐用于Java/Kotlin兼容项目）
1. 项目级 build.gradle（或 build.gradle.kts）中声明仓库：
确保移除所有 jcenter()，仅保留权威源：
// build.gradle (Project level)
buildscript {
repositories {
google()
mavenCentral() // ✅ 替代 jcenter()
}
dependencies {
classpath 'com.android.tools.build:gradle:8.4.0'
}
}
// 全局仓库（Android Gradle Plugin 7.0+ 推荐写法）
plugins {
id 'com.android.application' version '8.4.0' apply false
id 'org.jetbrains.kotlin.android' version '1.9.20' apply false
}
repositories {
google()
mavenCentral() // ✅ 必须启用
}2. 模块级 app/build.gradle 中添加依赖：
dependencies {
// ✅ Gson 官方坐标（已同步至 Maven Central）
implementation 'com.google.code.gson:gson:2.10.1'
// 若使用 Kotlin，建议额外引入 type adapter 支持（非必需但更健壮）
implementation 'com.squareup.moshi:moshi-kotlin:1.15.0' // 示例：备用方案预埋
}⚠️ 注意事项：
- 不要手动添加 jcenter() —— 它不仅无效，还可能触发Gradle警告甚至构建失败；
- 避免使用过时版本（如 2.8.0 以下），新版修复了Android R+的反射限制问题；
- 若启用R8/ProGuard，请保留Gson默认规则（AGP 4.2+ 自动处理，无需额外 proguard-rules.pro 条目）。
? 更现代的替代方案（推荐新项目采用）
虽然Gson仍可用，但以下方案在类型安全、编译期性能和Kotlin原生支持上更具优势：
| 方案 | 适用场景 | 配置示例 | 优势 |
|---|---|---|---|
| Moshi | Kotlin优先、需运行时灵活性 | implementation 'com.squareup.moshi:moshi:1.15.0' implementation 'com.squareup.moshi:moshi-kotlin:1.15.0' |
编译期生成Adapter、零反射、Kotlin内联类友好 |
| Kotlinx Serialization | 纯Kotlin项目、协程深度集成 | implementation 'org.jetbrains.kotlinx:kotlinx-serialization-json:1.6.3' | 无反射、与Kotlin语言特性深度绑定、支持@Serializable注解一键序列化 |
例如，使用 Kotlinx Serialization 的极简示例：
@Serializable
data class User(val name: String, val age: Int)
// 序列化
val json = Json.encodeToString(User("Alice", 25))
// 反序列化
val user = Json.decodeFromString<User>("""{"name":"Alice","age":25}""")✅ 总结建议
- 存量项目：立即替换 jcenter() 为 mavenCentral()，升级Gson至 2.10.1，可快速恢复构建；
- 新项目开发：优先评估 Moshi 或 Kotlinx Serialization —— 它们提供更好的可维护性、更小的APK体积及更强的类型保障；
- 长期维护视角：避免硬编码版本号，改用 versionCatalogs（libs.versions.toml）统一管理依赖版本，提升工程可扩展性。
通过以上配置，你不仅能彻底解决 Cannot resolve symbol Gson 错误，更能为项目构建起面向未来的JSON处理基础设施。
