代码质量门禁概述：为什么需要代码质量门禁？Lint与Detekt简介
什么是代码质量门禁？
代码质量门禁，说白了就是在代码合入主干之前，设一道自动化的“安检闸机”。你提交的代码必须通过一系列静态检查，才能顺利合并。如果检查没通过——嗯，对不起，你的PR会被拦住，直到问题修复为止。
我个人习惯把这个门禁比喻成机场安检。你想想看，如果谁都能随便带着违禁品上飞机，那不乱套了？代码仓库也一样。没有门禁，坏味道、潜在bug、格式混乱的代码就会悄悄溜进主分支，最后让整个项目变得难以维护。我从入行到现在，见过太多因为“先合进去再说”导致的灾难了。
核心观点： 代码质量门禁不是用来限制开发效率的，而是用来保护项目长期健康的。它把质量检查左移到代码提交阶段，而不是等到上线才暴露问题。
为什么需要代码质量门禁？
你可能觉得“代码规范我们开会说过了，大家自觉遵守就行”。但我得说，这种想法太理想了。人在疲劳、赶进度、或者压力大的时候，很容易忽略细节。我记得有一次项目紧急上线，一位同事忘了删除调试日志，结果把内网IP打到了生产环境……从那以后，我再也不信“大家会注意”这种话了。
我们来看看没有门禁时常见的几种痛：
- 风格不统一： 有的用4空格缩进，有的用Tab，有的方法名全小写，有的驼峰——光看着就头大。
- 潜在bug漏掉： 空指针、类型不匹配、未关闭的资源……这些靠人眼review很难100%覆盖。
- 复杂度失控： 大函数、深度嵌套、循环复杂度爆炸——代码变得像迷宫一样。
- 团队沟通成本高： 每次code review都在讨论格式问题，真正逻辑上的问题反而没时间深究。
有了门禁，上面这些问题就能自动化拦截。你只需要在CI流水线里配置好规则，提交代码后机器自动跑一遍，不合格的直接打回。有什么好处？
| 维度 | 无门禁 | 有门禁 |
|---|---|---|
| 代码风格 | 人工检查，费时且不统一 | 自动检查，一次配置到处执行 |
| 潜在缺陷 | 靠reviewer经验，容易遗漏 | Lint/Detekt静态分析，覆盖广泛 |
| 复杂度控制 | 很少主动量化 | 可设定阈值，超标即拒绝 |
| 团队效率 | reviewer花费大量时间纠正格式 | 机器搞定低级问题，人类专注逻辑 |
Lint 与 Detekt 是什么？
刚才提到了“静态检查”，在Android/Kotlin世界里，两个最主流的工具就是Android Lint和Detekt。它们虽然都是做静态分析的，但侧重点很不一样。
Android Lint
Android Lint 是 Google 官方提供的静态代码扫描工具，内嵌在Android Gradle插件里。它主要关注：
- Android API的正确使用（比如在非UI线程更新View）
- 性能问题（比如用SparseArray代替HashMap）
- 国际化问题（硬编码字符串）
- 资源优化（未使用的资源、图片过大等）
说白了，它是专门为Android项目量身定做的“安检员”。我在项目中用过它抓出过很多隐藏的适配bug，比如在低版本API上用了高版本方法——这种事人眼真的不容易发现。
Detekt
Detekt 是一个专注于 Kotlin 代码的静态分析工具，由社区维护。它更擅长检查：
- 代码复杂度（圈复杂度、方法长度、类深度）
- 代码风格（命名规范、排版）
- 潜在代码坏味道（过多参数、过度嵌套）
- 注释规范
举个例子，Detekt 可以设置“方法不能超过20行”，如果你写了一个50行的怪物方法，它直接给你亮红灯。这对保持代码整洁非常有用。
两者对比
| 维度 | Android Lint | Detekt |
|---|---|---|
| 适用语言 | Java/Kotlin（侧重Android） | Kotlin（纯Kotlin） |
| 检查范围 | Android API、资源、性能、安全 | 代码复杂度、风格、坏味道 |
| 内置规则 | 200+ 默认规则 | 100+ 默认规则，可自定义 |
| 自定义能力 | 支持配置lint.xml | 支持YAML配置，可编写自定义规则 |
| 输出格式 | XML、HTML、命令行 | XML、HTML、SARIF等 |
| 典型应用场景 | Android专有问题的闸门 | Kotlin代码质量的闸门 |
我的建议： 两个工具不要二选一，而是配合使用。Android Lint 管“Android特有的事”，Detekt 管“Kotlin代码质量”。两者互补，才能建立完整的质量门禁。
它们如何协同工作？
你可能想问：这两个工具同时跑，会不会互相干扰？其实完全不会。它们在CI流水线中是两个独立的任务，先后顺序无所谓。我个人习惯是先跑 Detekt 检查代码复杂度，因为如果方法本身就写得很烂，后面Android Lint检查Android特性反而意义不大了。当然，你也可以反过来，看你的偏好。
下图展示了典型的质量门禁流程：
注意： 千万不要把门禁当成“摆设”。我见过一些团队配置了Lint和Detekt，但阈值设得极低，结果每次检查都通过，形同虚设。门禁的意义在于拦住真正有问题的代码，所以阈值要合理设定，并且随着项目演进持续调整。
如何落地？
好了，现在你知道了门禁是什么、为什么需要、以及用哪两个工具。接下来的课程我们会一步步教你在Android项目中集成Detekt和Android Lint，配置规则、设定阈值、集成到CI流水线，以及处理误报的方法。不过那是后面几章的事了——本章只是开个头，让你有个整体认识。
最后分享一个我的小经验：门禁生效的第一步，是让全团队达成共识。你想想，如果有个别同事觉得门禁“麻烦”，偷偷关掉或者绕过，那这套系统就白搭了。所以最好在项目启动时就定好规矩：“所有PR必须通过门禁才能合并”。
小结： 代码质量门禁 = Android Lint（管Android特性） + Detekt（管Kotlin质量） + 自动化CI执行。缺一不可。