依赖约束是Gradle 8起推荐的声明式版本控制机制，不引入依赖而施加解析规则，通过strictly/prefer校验整个依赖图，冲突时明确报错而非静默覆盖。
Gradle 的依赖约束（Dependency Constraints）不是用来“引入”依赖的，而是用来“定规矩”的——它在依赖解析阶段强制校验版本，防止传递依赖悄悄带入不兼容或不安全的版本。它比 force 更精准、更可追溯，尤其适合多模块项目中治理由第三方库引发的版本污染。
什么时候该用依赖约束
当你遇到这些情况时，约束就很有必要：
- 多个模块/第三方库都拉入了
com.fasterxml.jackson.core:jackson-databind，但版本不一致（比如 2.14.2 和 2.15.3），导致运行时报NoSuchMethodError - 某个底层库强制升级了 Netty 版本，而你的服务仍需兼容旧版协议，你希望整个项目统一锁定为
4.1.95.Final - 想让所有模块对
org.slf4j:slf4j-api使用同一版本，但又不想在每个dependencies块里重复写implementation
怎么声明依赖约束
约束必须写在 dependencies 块内，使用 constraints 闭包，并且只对可解析的 configuration（如 implementation、api）生效：
dependencies {
// 正常声明依赖
implementation 'org.springframework.boot:spring-boot-starter-web'
// 添加约束：不引入依赖，只设规则
constraints {
implementation('com.fasterxml.jackson.core:jackson-databind') {
version {
strictly '[2.15.0, 2.16.0[' // 必须在此区间，超出直接报错
}
}
implementation('io.netty:netty-bom') {
version { prefer '4.1.95.Final' } // 优先选这个，冲突时降级也不允许
}
}
}
注意：strictly 表示硬性边界，prefer 表示倾向性选择；两者结合能兼顾严格性和灵活性。
立即学习“Java免费学习笔记（深入）”；
和 libs.versions.toml 配合使用
如果项目已启用 libs.versions.toml，可以在 toml 文件中定义约束别名，再在构建脚本中引用：
在 gradle/libs.versions.toml 中：
[versions]
jackson = "2.15.3"
netty = "4.1.95.Final"
[libraries]
jackson-databind = { group = "com.fasterxml.jackson.core", name = "jackson-databind", version.ref = "jackson" }
[constraints]
jackson-databind = { group = "com.fasterxml.jackson.core", name = "jackson-databind", version.ref = "jackson" }
然后在 build.gradle.kts 中：
dependencies {
implementation(libs.spring.web)
constraints {
implementation(libs.constraints.jackson.databind)
}
}
这样既保持集中管理，又把约束逻辑显式暴露出来，便于审计和协作。
约束与 force 的关键区别
约束是“声明规则”，force 是“强行覆盖”。它们的区别直接影响构建稳定性：
- 约束会在依赖图解析前介入，发现冲突立即中断构建并报错，逼你直面问题
-
force是后置覆盖，可能掩盖真实兼容性问题，比如 A 模块依赖guava:31.0-jre，B 模块依赖guava:32.0.0-jre，force会静默选 32.0，但 A 模块里的 API 可能已被移除 - 约束支持语义化范围（如
strictly、prefer），force只能指定唯一版本
推荐新项目默认用约束，老项目迁移时可先用 prefer 过渡，再逐步收紧为 strictly。
