启用sbt缓存解析后项目运行时异常的原因排查

启用sbt缓存解析配置updateOptions := updateOptions.value.withCachedResolution(true)后，项目无法正常运行：

• 首先触发SLF4J类路径日志缺失错误，显式添加logback-common等组件后解决；
• 随后出现Jackson相关问题：项目已显式引入Jackson 2.13版本，并通过dependencyOverrides强制使用版本>2.12，但运行sbt test时抛出方法未找到错误：

  [error] Uncaught exception when running ...: java.lang.NoSuchMethodError: 'com.fasterxml.jackson.core.util.JacksonFeatureSet com.fasterxml.jackson.core.JsonParser.getReadCapabilities()'
  [error] sbt.ForkMain$ForkError: java.lang.NoSuchMethodError: 'com.fasterxml.jackson.core.util.JacksonFeatureSet com.fasterxml.jackson.core.JsonParser.getReadCapabilities()'
  [error]     at com.fasterxml.jackson.databind.DeserializationContext.<init>(DeserializationContext.java:212)
  

• 检查依赖图发现部分依赖引用Jackson 2.6、2.11版本，但调试时类路径中未找到2.12之前的jackson-databind或相关Jar包，却出现仅在2.12+版本存在的方法未找到错误，疑似旧版本Jackson被调用。

疑问 #

1. 为何启用缓存解析会改变运行时行为？
2. 未在类路径中显示的Jackson旧版本为何会被调用？

1. 缓存解析改变运行时行为的原因 #

sbt缓存解析的核心是复用历史解析的依赖树缓存来提速，但它的冲突处理逻辑和非缓存模式存在差异：

• 非缓存模式下，sbt会全量遍历所有依赖，严格执行dependencyOverrides的版本强制替换规则；
• 缓存模式下，若缓存的依赖树已包含旧版本Jackson引用且缓存未失效，sbt会跳过部分冲突校验步骤，导致旧版本依赖未被正确替换，最终混入运行时类路径；
• 此外，缓存解析可能打乱依赖加载顺序，旧版本Jar包被优先加载后，类加载器会先加载旧版JsonParser类，后续新版本无法覆盖已加载的类。

2. 类路径未显示的旧Jackson被调用的可能原因 #

这种情况多是类加载层面的隐性问题导致：

• fork进程类加载缓存：sbt test默认会fork新JVM，但sbt可能复用之前fork进程的类加载缓存，即便当前类路径已更新，缓存里的旧版本类仍会被调用。可尝试添加fork := true后执行sbt clean test，或用sbt clean test -no-fork强制不fork（注意可能影响测试隔离）；
• runtime/provided scope隐性依赖：部分依赖可能通过runtime或provided scope引入旧版Jackson，这类依赖不会出现在compile scope的依赖树中，但运行时会被加载。可执行sbt dependencyTree --runtime排查该scope下的依赖；
• Jar包合并/阴影化问题：若项目用shadowJar等插件合并Jar包，缓存解析可能导致合并后的Jar混入旧版Jackson类，而你检查的是原始依赖类路径，而非合并后的Jar内容；
• 本地仓库缓存污染：sbt本地仓库（默认~/.ivy2/cache）中可能存在损坏或版本错误的Jackson缓存文件，缓存解析会直接复用这些文件而非重新下载正确版本。可清理本地缓存后重试：rm -rf ~/.ivy2/cache/com.fasterxml.jackson，再执行sbt update clean test。

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