如何分阶段升级依赖宏库的多项目SBT构建至Scala 3？

优先升级无宏依赖的模块 #

• 先梳理仓库所有模块，标记出完全不依赖任何宏库的模块——比如纯业务工具类、不带JSON宏推导的数据模型模块。
• 直接将这些模块升级到Scala 3，无需处理宏相关问题，作为整个升级的基础模块。
• 依赖这些Scala 3模块的Scala 2项目，仅需添加-Ytasty-reader编译选项即可实现兼容。

依赖宏的模块采用双版本过渡策略 #

• 对依赖scala-logging、circe这类未支持Macro Mixing的模块，暂时保留Scala 2版本，同时添加Scala 3交叉编译配置：

  crossScalaVersions := Seq("2.13.12", "3.3.1")
  

• 在Scala 3编译分支中，替换宏依赖为非宏替代方案：比如circe改用circe-generic-extras手动编写编解码逻辑，scala-logging直接用Logger(getClass)代替宏生成的懒加载实例。
• 先确保Scala 3版本能独立编译通过，再逐步将依赖该模块的其他项目切换到Scala 3版本的依赖。

封装宏依赖，隔离影响范围 #

• 把对宏库的调用封装到单独的小模块中，比如创建logging-adapter模块，内部处理scala-logging的宏使用，对外提供无宏的getLogger接口。
• 业务模块仅依赖这个适配器模块，后续升级时只需修改适配器的实现（比如Scala 3版本改用原生Logger实例），业务代码无需改动。

利用SBT条件配置适配不同Scala版本 #

• 在build.sbt中根据当前编译的Scala版本，动态切换依赖和编译选项：

  libraryDependencies ++= {
    if (scalaVersion.value.startsWith("3.")) {
      // Scala 3使用非宏依赖
      Seq("io.circe" %% "circe-generic-extras" % "0.14.6")
    } else {
      // Scala 2保留原宏库
      Seq("io.circe" %% "circe-generic" % "0.14.6")
    }
  }
  

• 仅给真正依赖Scala 3模块的Scala 2项目添加-Ytasty-reader选项，避免冗余配置：

  scalacOptions ++= {
    if (crossScalaVersions.value.exists(_.startsWith("3.")) && scalaVersion.value.startsWith("2.")) {
      Seq("-Ytasty-reader")
    } else {
      Nil
    }
  }
  

分批次推进，逐步淘汰Scala 2版本 #

• 先实现所有模块的双版本编译，CI同时运行Scala 2和3的构建任务，确保兼容性。
• 从最底层模块开始，逐个将上层依赖切换到Scala 3，待所有模块稳定运行在Scala 3后，彻底移除Scala 2相关编译配置。

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