platform()是核心，因BOM本质是版本声明清单而非实际库，必须用它显式声明为依赖约束源；若误用api()或implementation()引入BOM坐标，会导致下载失败或classpath污染，且显式版本声明会优先覆盖BOM约束。
直接用 platform() 引入 BOM，就能让 Gradle 自动对齐所有被它覆盖的依赖版本——但前提是 BOM 本身得写对、引入方式得匹配、且不能被其他 force 或 constraints 意外覆盖。
为什么 platform() 是核心，而不是 api() 或 implementation()
BOM 本质不是库，而是“版本声明清单”，Gradle 要求你用 platform() 显式告诉它：“请把下面这个坐标当作依赖约束源，而不是要打包进 classpath 的实际依赖”。
-
implementation platform('org.springframework.boot:spring-boot-dependencies:3.2.4')✅ 正确：触发版本解析时优先采用 BOM 内声明的版本 -
implementation 'org.springframework.boot:spring-boot-dependencies:3.2.4'❌ 错误：会尝试下载一个不存在的 jar（BOM 是 pom-only） -
api platform(...)❌ 不必要：BOM 不参与编译期 API 合并，api反而可能引发 IDE 误判或重复暴露
如果你看到 NoClassDefFoundError 依然存在，大概率是某处写了 implementation 'xxx:1.2.3' 显式指定了版本，直接绕过了 BOM 约束。
自定义 BOM 时，constraints 和 allowDependencies() 怎么配
自己发 BOM（比如公司内部统一版），必须用 java-platform 插件，并明确区分“约束”和“实际依赖”：
- 在 BOM 项目的
build.gradle中，constraints { api(...) }是唯一推荐写法，它只声明版本，不拉取代码 - 必须加
javaPlatform { allowDependencies() }，否则 Gradle 默认禁止任何dependencies块出现在 BOM 工程里（这是安全默认） - 别在 BOM 里写
implementation或runtimeOnly——哪怕只是测试用，也会污染下游项目的 classpath
示例片段：
plugins { id "java-platform" }
javaPlatform { allowDependencies() }
dependencies {
constraints {
api("com.google.guava:guava:33.2.0-jre")
api("org.slf4j:slf4j-api:2.0.13")
}
}
多 BOM 共存时，谁的版本最终生效
Gradle 按声明顺序解析 BOM，后声明的 BOM 会覆盖前面同名依赖的版本。比如：
implementation platform('org.springframework.boot:spring-boot-dependencies:3.2.4')implementation platform('com.example:my-bom:1.5.0')
若两个 BOM 都声明了 org.junit:junit-jupiter，则以 my-bom:1.5.0 里的版本为准。但注意：platform() 不会覆盖你显式写的 implementation 'org.junit:junit-jupiter:5.10.0' ——显式版本永远最高优先级。
排查冲突最直接的方式是运行：./gradlew dependencies --configuration runtimeClasspath | grep junit，看实际解析出的版本来源。
Android 项目里用 BOM 容易漏掉的关键点
Android Gradle Plugin（AGP）7.0+ 对 platform() 支持良好，但有三个隐蔽坑：
- 别在
androidTestImplementation或testImplementation里漏掉 BOM 引入——测试 classpath 是独立的，BOM 不自动继承 - 如果用了
version catalogs（libs.versions.toml），BOM 必须通过platforms块声明，不能塞进libraries；否则引用时会报Cannot resolve symbol 'platforms' -
android.useAndroidX=true和android.enableJetifier=false必须开启，否则 BOM 里 androidx 相关版本可能被 Jetifier 错误重写
真正麻烦的从来不是怎么写 BOM，而是当团队里有人在某个 module 的 build.gradle 里偷偷加了一行 implementation 'com.squareup.okhttp3:okhttp:4.12.0' ——这行代码会静默破坏整个 BOM 的约束效力，且 IDE 和 CI 都不会报警。
