complexity 规则是什么
ESLint 内置的 complexity 规则限制函数的圈复杂度，默认阈值是 20，可以在配置里收紧到符合团队基线的数值。它适合用来标记分支多、理解成本高的函数，作为评审时判断要不要拆分的一个量化参考。
基本信息
| 规则名 | complexity |
|---|---|
| 默认阈值 | 20 |
| 配置方式 | 把规则写成数组并传入数值 |
| 统计口径 | 函数级别的分支判定点数量 |
典型使用场景
- 项目刚引入检查：先看现有分布，再决定阈值
- 核心模块加严：对关键目录设置更低的阈值
- 评审辅助：把超过阈值的函数列为重点阅读对象
- 拆分效果验证：重构前后对比同一函数的复杂度
- 避免一刀切：新增代码与存量代码使用不同配置
设定阈值前的准备
- 先统计现有函数的复杂度分布
- 取多数函数能达到的值作为目标
- 对确认复杂的存量函数列入豁免清单
- 阈值调整单独提交，便于回溯
配置示例
配置示例
// 在 flat config 里收紧阈值
export default [
{ files: ["**/*.js"], rules: { complexity: ["error", 15] } },
];阈值与实践
| 阈值 | 影响 |
|---|---|
| 20，即默认值 | 接近无约束，只能拦住极端函数 |
| 15 左右 | 多数团队可以接受的折中 |
| 10 以下 | 噪声明显增加，需要配套豁免机制 |
阈值要按现状基线定：先看分布，再定多数函数能够达到的目标值。
和复杂度一起看什么
- 变更频率：高频改动的复杂函数优先拆分
- 测试覆盖：复杂分支是否有对应用例
- 文件长度：单个函数短但同类函数塞满文件属于组织问题
- 团队约定：新代码与存量代码可以使用不同阈值
在评审中的用法：把超过阈值的函数列为重点阅读对象，先判断能否拆分，再决定是否豁免。
阈值只是一种提示：真正的判断标准仍然是这段逻辑能否被讲清楚、能否被测试覆盖。
复杂度要与文件长度一起看：单个函数都不长，但文件里塞满同类函数时，问题往往在组织方式而不是复杂度。
把阈值设得过低：存量代码无法收敛，规则最终会被整体关闭。