strictly 是 Gradle 原生强制版本语义，作用于单个依赖声明，冲突时直接报错；force 是全局覆盖策略，易引发隐式冲突且不报错。
Gradle 给依赖设置严格版本要求，核心是用 strictly 限定解析行为——它不是“建议用这个版本”，而是“必须用这个版本，否则构建失败”。这比 force 更可靠，也比 BOM 更精准控制单个依赖。
strictly 和 force 的区别在哪
strictly 是 Gradle 原生语义，作用于依赖声明本身；force 是 resolutionStrategy 的全局强制策略，容易误伤其他依赖。前者更细粒度、更可预测。
-
strictly只影响该依赖项及其子图，不影响其他无关依赖 -
force会覆盖整个依赖图中所有匹配的坐标（哪怕来自不同模块），容易引发隐式冲突 - 当多个
strictly声明冲突（比如两个模块分别要求strictly '1.9'和strictly '2.0'），Gradle 直接报错，不妥协 -
force不会报错，而是静默覆盖，问题可能拖到运行时才暴露
在 dependencies 块里直接写 strictly
最常用、最推荐的方式：在 dependencies 块中对具体依赖使用 version { strictly 'x.y.z' }。
dependencies {
implementation('commons-codec:commons-codec') {
version { strictly '1.9' }
}
implementation('org.springframework.boot:spring-boot-starter-web')
}
- 适用于你明确知道哪个传递依赖需要降级/锁定（比如因 API 兼容性必须用
1.9） - 只对当前模块生效，多模块项目中每个模块可独立控制
- 不依赖
configurations.all，避免污染 testRuntimeClasspath 等非预期配置 - 注意：不能和动态版本共存，如
'1.+'或latest.release会直接导致构建失败
配合 dependency locking 使用更安全
单独用 strictly 能控住版本，但无法防止本地缓存或网络波动导致的解析漂移。gradle.lockfile 是最终防线。
- 启用锁文件后，
strictly声明会被记录进gradle.lockfile，CI 构建时强制校验 - 运行
./gradlew dependencies --write-locks后，务必提交生成的gradle.lockfile - 在
gradle.properties中显式设org.gradle.dependency-locking.ignoreFailures=false，确保锁失效时构建中断 - 若某依赖被
strictly锁定但实际不可达（如私有仓库临时宕机），构建立刻失败，而不是退化到其他版本
strictly 不起作用的常见原因
写了 strictly 却发现版本没生效？大概率是以下情况之一。
- 依赖被更高层的 BOM（如
platform('org.springframework.boot:spring-boot-dependencies')）覆盖 —— BOM 的约束优先级高于strictly，需检查 BOM 是否已包含冲突版本 - 该依赖通过
api或compileOnly引入，而strictly声明在implementation下，未覆盖到 —— 需在对应配置块中重复声明 - 模块未启用 dependency locking，或
gradle.lockfile未提交/过期 ——strictly在无锁环境下仍可能被某些插件绕过 - 用了旧版 Gradle（strictly 支持不完整或行为异常 —— 当前（2026年）建议至少用 Gradle 7.6+
真正关键的不是“怎么写”，而是理解 strictly 是一种契约：它把版本选择权从 Gradle 手中拿走，交给你自己签章确认。一旦签了，就不能反悔，也不能指望缓存或网络替你兜底。
