复杂度不是代码风格问题，是维护成本问题。一个圈复杂度 25 的函数，改一行要跑三遍脑内模拟；一个耦合度失控的模块，新人两周都摸不清调用链。工具能把这些隐形成本量化出来，但前提是用对、配对。
复杂度到底在量什么
圈复杂度（Cyclomatic Complexity）数的是独立路径条数，本质是判定节点加一。它决定了一个函数最少需要多少个测试用例才能覆盖所有分支。认知复杂度（Cognitive Complexity）走的是另一条路，按嵌套层级加权，嵌套越深扣分越狠，更贴近人读代码时的真实负担。
两个指标要一起看。一个平铺的 switch 有二十个分支，圈复杂度很高，但认知复杂度尚可，读起来并不痛苦；反过来，三层嵌套的 if-else 只有八个分支，认知复杂度却能飙上去。只盯一个数字做重构，容易改错地方。
Python 项目里的实测路径
Radon 是 Python 生态里最省事的入口。装完直接扫：
pip install radon
radon cc path_to_project -s -a
-s 显示每个函数的评分，-a 给出项目平均值。输出按 A 到 F 分级，A 是 1-5，B 是 6-10，C 是 11-20。业界常把 10 当分水岭，超过就该拆。但别机械执行——先加 -n C 只看 C 级以上的函数，噪音立刻少一大半：
radon cc path_to_project -n C -s
想看整体健康度，换 radon mi，输出可维护性指数（Maintainability Index），0-100 打分，低于 20 基本属于”碰之前先写测试”的区间。这两个命令塞进 CI 的 shell 步骤里，几秒钟出结果，比人工 review 靠谱。
企业级方案的真实边界
SonarQube 常被当成万能钥匙，实际情况要复杂些。社区版从 10.x 起，C/C++、COBOL 等语言的分析能力已经移出内置范围，需要单独部署对应插件，部分还要商业授权。选型时先确认你的主力语言在目标版本里是否开箱可用，别等到接入当天才发现要加钱。
它的价值在于技术债务量化和质量门禁。复杂度阈值不在项目设置里随便填，而是挂在质量门（Quality Gate）的条件上，比如”新增代码中函数认知复杂度超过 15 的占比不得高于 5%”。注意是新增代码——这是 SonarQube 设计上的聪明之处，它默认不拿历史包袱卡你，只拦新提交。遗留系统改造时这一点尤其关键，否则门禁第一天就红。
轻量场景可以看 Lizard。单文件 Python 脚本，无依赖，支持十几种语言，输出是纯文本，特别适合塞进 pre-commit 钩子或 Jenkins 的 shell 步骤。代价是没有可视化，也没有趋势追踪。
阈值怎么定才不误伤
固定阈值是个陷阱。核心算法、状态机、协议解析器天生复杂度高，硬压到 10 以下只会逼出更烂的代码——把逻辑拆成一堆互相调用的碎片函数，总复杂度没降，可读性反而崩了。
可行的做法是分层设阈：业务编排层卡紧，认知复杂度 15 封顶；基础设施和算法层放宽到 25，但强制要求配套单元测试覆盖率和函数头注释说明设计意图。Checkstyle 里配 CyclomaticComplexity 模块时同理，max 属性按包路径分规则，别全局一个值：
<module name="CyclomaticComplexity">
<property name="max" value="10"/>
</module>
对自动生成的代码（protobuf 产物、ORM 映射类）直接排除扫描路径，否则报告里全是假阳性，团队很快就会学会无视告警——这比不装工具更糟。
把治理嵌进交付流水线
工具跑在本地只是个人习惯，跑在流水线上才是团队约束。推荐三个卡点：提交前用 Lizard 或 radon 做增量扫描，只查改动文件；合并请求阶段由 SonarQube 质量门判定，不达标直接阻断；每周跑一次全量报告，看复杂度分布的趋势曲线而不是绝对值。
趋势比快照有信息量。平均值从 14 降到 8 固然好看，但如果是靠把大函数拆成十几个中等函数换来的，总复杂度可能没变，只是被摊薄了。看 P90 分位数和超标函数数量，比看均值诚实得多。
最后一句实话：工具能告诉你哪里烂，但拆不拆、怎么拆，取决于你对这块代码变更频率的判断。半年没人碰的高复杂度模块，优先级排在天天改的中等复杂度模块后面。复杂度治理的本质是投资回报排序，不是追求一张全绿的报告。
ID:7513
