exclude 对 files() 无效，因该方式引入的 JAR 无元数据，Gradle 不解析其内部结构；需改用 flatDir、重打包、发布为 Maven 模块或引入源码等方案。
exclude 为什么没生效：Gradle 不解析 files() 依赖的元数据
你写了 implementation files('libs/sdk.jar') { exclude group: 'org.slf4j' }，但运行时依然加载了 slf4j 的类——这不是 Gradle 忘记执行，而是它压根没机会执行。因为 files() 引入的 JAR 是“无坐标、无元数据、无依赖图”的纯二进制文件，Gradle 不会去读它的 META-INF/MANIFEST.MF，也不会解压扫描它内部打包了哪些 class 或嵌套了哪些 jar。所以 exclude 这种基于依赖图谱的操作，在 files() 上是语法合法但语义无效的。
怎么确认某个 JAR 是否真把依赖打进了自己内部
别猜，直接看内容：
- 用
jar -tf libs/sdk.jar | grep -i "slf4j\|logback"查是否有org/slf4j/目录或 class 文件 - 如果输出里有大量
org/slf4j/开头的路径，说明 slf4j 已被“shaded”进去了，不是传递依赖，而是已编译进字节码 - 如果只看到
META-INF/MANIFEST.MF且里面有Class-Path:行，那才是传统依赖声明，但 Gradle 仍不会读取它
真正能起作用的四种替代方案
核心思路：让这个 JAR 进入 Gradle 的依赖解析流程，而不是当黑盒塞进来。
- 用
flatDir+name声明，给它伪造坐标：repositories { flatDir { dirs 'libs' } }，然后写implementation name: 'sdk', ext: 'jar'，再加exclude - 手动解压 JAR，删掉不需要的 class（如
org/slf4j/**），再重新打包（注意：若原包有签名，需先jarsigner -verify确认是否允许修改） - 用
gradle publishToMavenLocal把它发布为本地 Maven 模块，补上pom.xml声明依赖关系，后续就能用标准方式排除 - 改用
implementation引入其源码模块（如有），或推动上游提供非 shaded 版本——这是最可持续的解法
排除后仍看到类的另一个常见原因：JVM 类加载器顺序
即使你成功排除了某个依赖，如果项目里还有另一个 JAR（比如通过 fileTree 或 compileOnly 引入）也含相同 class，JVM 仍可能加载它。关键点在于：
-
files()和fileTree()引入的 JAR 会进入compileClasspath，但不参与 Gradle 的版本仲裁 - 它们的 class 被加载顺序取决于
classpath中的排列位置，而这个顺序在不同构建环境（IDE vs CLI）、不同 Gradle 版本中可能不一致 - 验证方式：运行
./gradlew :app:dependencies --configuration runtimeClasspath，检查该类是否还出现在输出中；再用java -verbose:class -jar app.jar 2>&1 | grep slf4j看实际加载来源
最常被忽略的一点：exclude 只影响依赖图谱的构建，不改变已存在的字节码。如果你面对的是一个已经把别人代码全打进来的 fat jar，那你要处理的不是“依赖”，而是“二进制污染”。这时候得动刀——要么重打包，要么换源，没有捷径。
