文章目录Spotless让代码格式化这件事在构建时一并解决1、 它解决的是什么问题2、 用起来什么感觉3、 比同类工具强在哪4、 支持范围5、 适合什么场景接入Spotless让代码格式化这件事在构建时一并解决Spotless 在 GitHub 上已经拿到 5,541 个 Star。DiffPlug 开源的这个项目专做一件事就是在 Gradle、Maven、SBT 这些构建工具里把代码格式化挂进流程。Java、Kotlin、Scala、Python、TypeScript、SQL、Markdown 等 30 多种语言它都支持加上 50 多个格式化器可组合使用。1、 它解决的是什么问题团队协作里代码格式争议不是大事但很烦人。靠人手动改很容易漏靠 IDE 一键格式化又得依赖每个人本地都装上同一套规则和插件。CI 上跑 checkstyle、ktlint 这类工具能拦住不规范代码但报错之后还得人回头改反馈链太长。Spotless 的思路是把格式化做成构建任务的一部分。gradlew build不通过就提示哪些行越界跑一下gradlew spotlessApply自动修再 build 就过。这等于把格式从 review 阶段挪到了构建阶段本来就跑在 CI 里的步骤顺手就处理了。2、 用起来什么感觉就两步。配置文件里声明要格式化哪些文件、用哪个格式化器然后跑 check 或者 apply。Maven 端的体验类似mvn spotless:check看违规mvn spotless:apply修复。命令不对工具会提示你跑哪个命令。报错信息具体到哪一行的哪一处缩进、空格有问题不用自己猜。3、 比同类工具强在哪格式化器本身不少见clang-format、google-java-format、ktlint、prettier 都是各语言生态里成熟的东西。Spotless 没有再造一个格式化器而是把已有的 clang-format、google-java-format、ktlint、prettier 统一到一个接口下让你用一个配置就能调用任何一种。需要从 google-java-format 切到 palantir-java-format只改一行配置。它处理了格式化集成里那堆隐形问题换行符在 Windows 和 Unix 之间不一致文件编码识别错误导致中文乱码格式化器不幂等跑两次结果不一样git 历史里只想格式化新增文件不想动整个仓库。这些坑它都封装掉了使用者不必自己处理。Ratchet 功能是另一个加分项。配ratchetFrom origin/main之后Spotless 只检查自那个 ref 以来改过的文件。老仓库接入不用担心一次提交把几万个文件都重格式化掉PR diff 也能保持干净。4、 支持范围构建工具覆盖 Gradle、Maven、SBT。语言覆盖 Java、Kotlin、Scala、Groovy、C、C、C#、Go、Python、TypeScript、JavaScript、JSON、YAML、SQL、Shell、Protobuf、Markdown 等。每种语言至少接两到三个格式化器可选。它的 feature matrix 是一张开放表_gradle 列打勾最多的那一列sbt 列少一些剩下空格是社区可以补的。项目方明确说不需要把整张表填满才能合并 PR你想给 Bazel 加支持或者给某个新格式化器接进来只要在你用的那个 build 工具下能跑就行。这也是它长尾覆盖这么多格式的原因。5、 适合什么场景接入Java 或 Kotlin 主力、想在 CI 里强制统一代码风格的团队老仓库想引入格式化但担心改动失控需要 ratchet 限制范围的项目多语言混编仓库希望用一套构建工具同时管 Java、TypeScript、SQL、YAML 的格式给开源项目贡献代码、想降低 review 中格式争议的维护者刚开始接入可以只开一个语言的 check 任务配合 ratchetFrom 限制到主干分支以来的改动成本低、收益直接体现在 PR diff 里。chetFrom 限制到主干分支以来的改动成本低、收益直接体现在 PR diff 里。