Back

代码度量详解：什么是圈复杂度？

OpenReplay Team

May 15, 2026 · 2 min read

你正在审查一个 pull request，发现某个函数已经膨胀到需要处理八种不同的情况——用户角色、功能开关、边界情况、回退逻辑。它通过了测试。它能正常工作。但总感觉哪里不对劲。这种感觉是有名字的，而且可以用一个数字来衡量。

圈复杂度（Cyclomatic Complexity）是一种代码质量度量指标，用于衡量一个函数中存在多少条独立的执行路径。数值越高，代码中的分支逻辑就越多——也就越难以阅读、测试和维护。

核心要点

圈复杂度统计函数中的独立路径数量，为分支逻辑提供一个可量化的信号。
快速计算方法：从 1 开始，每遇到一个分支语句（如 if、&&、||、case 或三元运算符）就加 1。
它不同于认知复杂度——认知复杂度衡量代码对人类阅读者的理解难度，而非路径数量。
ESLint 和 SonarQube 等工具可以自动跟踪复杂度，并标记超过可配置阈值的函数。
使用守卫子句、抽取辅助函数、描述性布尔变量和查找表来降低复杂度。

圈复杂度是如何计算的

该度量由 Thomas McCabe 于 1976 年提出，源自函数的控制流图。对于单个连通分量的实用公式为：

M = E − N + 2P

其中 E 是边的数量，N 是节点的数量，P 是连通分量的数量（对于单个函数通常为 1），M 是复杂度得分。

对大多数 JavaScript 开发者来说，你无需手动计算。一个简便方法：从 1 开始，然后为每个分支语句加 1——包括 if、else if、&&、||、for、while、case、三元运算符以及 catch 子句。某些工具还会统计可选链、默认值、逻辑赋值等结构。具体的计算规则在不同工具（如 ESLint 和 SonarQube）之间可能略有差异。

一个 JavaScript 示例：分支如何增加复杂度

// Cyclomatic complexity: 1
function getDisplayName(user: User): string {
  return user.name;
}

// Cyclomatic complexity: 6
function getDisplayName(user: User | null): string {
  if (!user) return "Guest";                     // +1
  if (user.isAdmin) return "Admin";              // +1
  if (user.displayName) return user.displayName; // +1
  if (user.firstName && user.lastName)           // +1 (if) +1 (&&)
    return `${user.firstName} ${user.lastName}`;
  return user.email;
}

每一个条件都增加一个分支。分支越多，需要测试的路径就越多——未来的修改也越有可能引发意想不到的问题。

这种模式在前端代码中随处可见：React 组件的渲染逻辑、包含多种 action 类型的 Redux reducer、表单校验处理器，以及基于权限的 UI 流程。

圈复杂度 vs. 认知复杂度

这两者相关但又有所不同。圈复杂度统计结构性分支——它是一种可测试性的信号。认知复杂度（由 SonarQube 推广）衡量代码对人类阅读者的理解难度，对嵌套和非线性流程的惩罚更重。

一个函数的圈复杂度可能很低，但仍然难以理解——例如，没有中间变量的深度链式方法调用。两种度量都有用，单独任何一种都不能反映全貌。

在你的 JavaScript 代码库中测量它

适用于前端团队的两个实用工具：

ESLint complexity 规则——直接在编辑器中标记超过可配置阈值的函数
SonarQube / SonarCloud——在整个代码库中报告圈复杂度和认知复杂度

ESLint 配置示例：

{
  "rules": {
    "complexity": ["warn", { "max": 10 }]
  }
}

阈值是可配置的——也应该如此。一个校验工具函数和一个 Redux reducer 不需要相同的上限。请根据代码的上下文调整阈值，而不是套用通用规则。

减少不必要复杂度的实用方法

当函数的得分攀升时，以下技巧会有帮助：

抽取函数——将独立的逻辑提炼为命名的辅助函数
使用守卫子句——尽早返回，而不是嵌套条件
简化条件表达式——用描述性变量替换复杂的布尔链
使用查找表——用对象或 Map 替代冗长的 switch 语句

目标并不是为了追求低分本身，而是让代码更易于测试、更易于修改，也更容易被下一位开发者理解。

结语

圈复杂度为你的代码分支逻辑提供了一个具体、可量化的信号。使用 ESLint 或 SonarQube 来跟踪它，设置适合你代码库的阈值，并将上升的分数视为重构的提示——而不是危机的信号。配合认知复杂度一起使用，可以更全面地了解可维护性。

常见问题

一个常见的指导原则是将函数的圈复杂度保持在 10 或以下。1 到 10 之间通常被认为是可控的，11 到 20 表明函数开始变得复杂，超过 20 通常是强烈建议重构的对象。合适的阈值取决于代码类型，因此请根据团队的实际情况进行调整。

圈复杂度对每个分支语句的计数是相同的，不论嵌套有多深。一个包含三个平行 if 语句的函数和一个包含三个嵌套 if 语句的函数得分可能相同。这正是认知复杂度存在的原因之一，因为它对嵌套增加了额外的权重，能更好地反映代码的阅读难度。

并不总是如此。高分意味着该函数值得仔细审视，但某些逻辑本身就是分支密集的，例如解析器、状态机或校验管道。请将该指标作为审查的提示而非严格的规则。如果函数经过充分测试、代码清晰且稳定，重构反而可能引入风险而带不来真正的收益。

代码行数衡量代码的体量，而圈复杂度衡量决策点的数量。一个 200 行但没有分支的函数复杂度为 1，而一个充满条件判断的 20 行函数得分可能要高得多。复杂度对可测试性和维护成本的预测能力更强，因为它反映了测试需要覆盖多少条路径。

Gain control over your UX

See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.