推荐 version catalog 与 java-platform（BOM）配合使用：前者实现项目内依赖命名与版本解耦，后者保障跨项目依赖版本强约束；二者职责互补，单独使用均存在短板——catalog 不干预依赖解析且无法保证传递依赖一致性，BOM 缺乏命名别名与 IDE 支持。
可以，而且推荐一起用——version catalog管「项目内依赖命名与版本解耦」，java-platform（BOM）管「跨项目/跨团队的依赖版本强约束」，二者职责不重叠，配合得当反而能解决纯用一种方式时的典型短板。
为什么不能只靠 version catalog 管所有版本？
version catalog（libs.versions.toml）本质是构建脚本的“常量定义表”，它让 implementation libs.androidx.core.ktx 这种写法可读、可复用、可集中维护。但它不参与 Gradle 的依赖解析决策，也不强制约束传递性依赖的版本。
- 如果你在 catalog 里写了
androidx-core-ktx = { version = "1.12.0" }，但某个间接依赖带进来androidx-core-ktx:1.10.1，Gradle 默认会按“最近声明优先”或“最高版本胜出”策略选一个——catalog 不会阻止它 - catalog 无法表达“这个 BOM 必须整体生效”这类语义，比如 Compose BOM 或 Spring Boot BOM 的内部模块版本协同关系，catalog 本身不具备这种“原子性约束”能力
- 多模块项目中，子模块若各自声明依赖，哪怕都引用同一个 catalog 别名，也无法防止某人手写
implementation "androidx.core:core-ktx:1.9.0"绕过 catalog
为什么不能只靠 BOM（java-platform）管所有依赖？
java-platform 插件生成的 BOM 是真正的“依赖约束中枢”，通过 constraints 块声明的版本会强制覆盖整个依赖图中的对应坐标，连 transitive 依赖也受控。但它不提供命名别名、不支持 IDE 自动补全、不便于在不同模块间共享同一组逻辑分组（比如 “networking”、“ui”、“test-utils”）。
- BOM 中只能写
api("com.squareup.okhttp3:okhttp:4.12.0")，没法像 catalog 那样定义okhttp = { group = "...", name = "...", version = "4.12.0" }再用libs.okhttp引用 - IDE 对 BOM 的支持弱：Android Studio 不会在
dependencies块里为 BOM 提供别名提示，你得记住完整坐标或复制粘贴 - 如果 BOM 发布后发现某依赖要降级，必须发新版本 BOM；而 catalog 修改后 reload 就生效，适合快速迭代阶段
怎么把两者真正串起来用？
核心思路：用 version catalog 定义 BOM 的坐标和版本，再在子模块中用 platform(...) 引入该 BOM —— 这样既保留 BOM 的强约束力，又享受 catalog 的可维护性和 IDE 支持。
- 在
gradle/libs.versions.toml中定义 BOM 坐标：[versions] compose-bom = "2026.09.00" spring-boot-bom = "3.3.5" [libraries] compose-bom = { group = "androidx.compose", name = "compose-bom", version.ref = "compose-bom" } spring-boot-bom = { group = "org.springframework.boot", name = "spring-boot-dependencies", version.ref = "spring-boot-bom" } - 在应用模块的
build.gradle中引入：dependencies { implementation platform(libs.compose.bom) implementation platform(libs.spring.boot.bom) // 后续依赖可省略版本，由 BOM 约束 implementation "androidx.compose.ui:ui" implementation "org.springframework.boot:spring-boot-starter-web" } - 若需局部覆盖 BOM 版本（如用 alpha 版 animation），仍可显式声明：
implementation "androidx.compose.animation:animation:1.13.0-alpha03"
—— 这会触发 BOM 自动对齐其依赖树，无需手动处理传递依赖
真正容易被忽略的是约束层级：BOM 的 api 约束只影响直接声明了 platform(...) 的模块；如果某个子模块没引入 BOM，它就完全不受控。所以 BOM 的引入点必须统一管控（比如放在根项目的 subprojects 块里），不能依赖每个模块自觉添加。
