Detekt简介：它到底是什么？
说实话，刚开始接触静态分析工具时，我总觉得“不就是检查代码格式吗？Ktlint不香吗？” 但真正深入项目之后才发现——嘿，Detekt这货完全是另一回事。
它不是一个简单的代码格式化器。它是一个静态分析框架。说白了，它能检测你代码中的坏味道、复杂度、潜在bug，甚至是架构层面的问题。
Detekt的核心特点
我列几个最让我印象深刻的点。你品，你细品。
- 高度可配置：每个规则都可以开关、调参。甚至能自己写规则
- 代码复杂度度量：Cyclomatic Complexity、Cognitive Complexity，这些它都能算
- 支持独立运行 & Gradle插件：CI/CD里随便集成
- 输出格式丰富：XML、HTML、SARIF……和SonarQube能无缝对接
- 基线（Baseline）机制：存量项目不会炸一片，慢慢整改
一句话总结：Ktlint管“好不好看”，Detekt管“好不好用”。
Detekt vs Ktlint —— 别再搞混了
| 维度 | Detekt | Ktlint |
|---|---|---|
| 定位 | 静态分析 + 度量 | 代码风格格式化 |
| 规则范围 | 坏味道、复杂度、潜在缺陷、性能 | 缩进、命名约定、空行等格式 |
| 定制能力 | 自定义规则 + 配置参数 | 几乎不可定制（除非手动关规则） |
| 运行方式 | CLI、Gradle、Maven | CLI、Gradle、IDE插件 |
| CI集成 | 完美支持，可输出报告 | 支持，但报告较弱 |
| 学习曲线 | 中等（配置较多） | 简单（几乎零配置） |
我之前在一个接手的老项目里，Ktlint跑一遍全是格式问题。但真正让人头疼的是——几百行的函数、空指针隐患、到处是空安全违规……这些Ktlint根本揪不出来。Detekt一跑，直接炸出80多个warning。嗯，从那天起我就在CI里把它俩一起上了。
Detekt的适用场景
别以为Detekt是万能神药。它也有自己的主场。
- 中大型项目：小项目搞它有点过头。但项目超过20个Kt文件，效果就很明显
- 团队规范落地：用它定义团队内部的质量红线，比口头约定靠谱一百倍
- 代码重构前“体检”：改之前先跑一遍基线，改完再对比，就知道有没有引入新问题
- CI门禁：比如设置阈值——复杂度超过15直接阻断build。这个我推荐过很多团队
我的习惯：新项目一开始就集成Detekt，配合Gradle配置，运行成本几乎为零。等代码写多了再想加，那才叫折腾。
Detekt的工作原理（一张图说清楚）
下面的图展示了Detekt从配置到报告输出的完整流程。你一看就明白。
注意：基线文件（baseline.xml）是存量项目的救星。第一次跑Detekt时生成一个基线，下次只报告新增的问题。这样就不会把整个团队劝退了。
我踩过的坑
曾经在一个20人团队里推广Detekt，第一次执行——2000多个warning。全团队炸了。后来我做了什么？
- 先配置
config/detekt/baseline.xml把存量问题全部压下去 - 只对新增代码开全部规则
- 在PR上只展示新增违规
两周后，大家就习惯了。三个月后，代码复杂度明显下降。
警告：别把Detekt的默认配置直接扔进大项目。一定要先用baseline，然后分阶段逐步放宽规则。否则“门禁”变成“门神”，没人理你。
小结
Detekt不只是一个检查工具。它是一种代码质量的文化工具。用它，你不只是修bug，更是让团队形成一种对“坏味道”的零容忍。