如何在Gradle中仅约束传递依赖版本，不将其添加为直接依赖

首先先澄清一个高频误解：你看到依赖报告顶层的C:2大概率不是真的成为了直接依赖，而是Gradle dependencies任务的展示逻辑问题——当传递依赖的版本被约束强制修改后，Gradle会把该依赖的节点提到顶层展示，方便感知版本变更，不代表它是项目直接引入的。

先验证依赖的真实来源 #

你可以用以下命令确认C的实际引入路径：

./gradlew dependencyInsight --dependency C --configuration runtimeClasspath

如果输出的「Requested by」字段显示来源是B而不是当前项目的坐标，说明C仍然是B的传递依赖，只是版本被你的约束调整为2，并没有被当成直接依赖。
如果要进一步确认发布产物（比如Maven POM）里没有C的直接依赖条目，可以执行生成POM的任务后检查对应文件，只要POM的<dependencies>标签里没有C的配置，就不会把C泄露为直接依赖。
如果验证后发现C确实被当成了直接依赖，先检查是否在dependencies块的非constraints区域误写了对C的直接依赖配置。

两种完全符合需求的配置方案 #

方案1：保留官方推荐的约束配置（修正使用方式）

Gradle的依赖约束（constraint）本身的设计就是仅作用于已存在的传递依赖，不会主动引入新依赖，只要你按照官方规范把constraints块嵌套在dependencies内部使用即可，正确写法如下：

dependencies {
    // 原有的直接依赖
    implementation 'B:1.0'

    // 约束块必须嵌套在dependencies内部
    constraints {
        implementation('C') {
            version {
                require '2'
            }
            because 'I cant use previous versions'
        }
    }
}

按照这个写法配置后，哪怕你主动删掉所有引入C的上游依赖（比如移除对B的依赖），C也不会出现在你的依赖列表里，完全符合不引入直接依赖的要求。

方案2：用ResolutionStrategy强制版本（零引入风险）

如果你希望更明确的控制逻辑、完全规避任何可能的依赖引入问题，可以直接在依赖解析阶段对传递依赖强制指定版本，这个方式只会修改已引入的传递依赖的版本，绝对不会主动引入新依赖：

// 放在build.gradle顶层即可
configurations.configureEach {
    resolutionStrategy.eachDependency { detail ->
        // 替换为你实际使用的C组件的group和name
        if (detail.requested.group == 'com.example' && detail.requested.name == 'C') {
            detail.useVersion '2'
            detail.because 'I cant use previous versions'
        }
    }
}

这个配置的逻辑是在所有依赖解析的最终阶段，对匹配条件的依赖强制替换版本，哪怕全项目没有任何路径引入C，也不会额外拉取C组件。

内容的提问来源于stack exchange，提问作者jbu