前面几节讲的是"怎么写"，这一节讲"怎么保证团队写出来的代码跟你一样好"。这题的面试形态很特别——它不考语法也不考 API，考的是你有没有一套能落地的质量保障机制。答得浅的人说"团队 review 很严格"，答得深的人会讲清"哪些交给机器、哪些必须留给人，以及告警怎么管"。
先把结论放在前面：Kotlin 代码质量保障分三层，越靠下越应该自动化，越靠上越需要人的判断。①工具层：ktlint（格式）、detekt（潜在缺陷）、Kotlin 编译器警告——机器管风格与确定性缺陷；②约定层：团队规范文档 + PR 模板 + 关键检查项——半强制；③设计层：架构边界、抽象选择、命名语义——只能靠人。核心原则是：把机器能查的规则化，人的 review 时间才腾得出来看设计。这一节的判断力就体现在"知道哪条规则该放进哪一层"。
机制背后的执行路径
先说清三个工具各自负责什么，避免职责重叠导致告警重复：
| 工具 | 负责 | 典型规则 | |---|---|---| | ktlint | 代码格式 | 缩进、换行、import 顺序、尾随空格 | | detekt | 潜在缺陷与复杂度 |NestedBlockDepth、LongMethod、MagicNumber、UnsafeCallOnNullableType| | 编译器警告 | 语言级风险 | 未使用变量、可疑的
