状态栏中“c: 5 m: 85 l: 20”表示当前函数的圈复杂度（c）、维护性指数（m）和逻辑行数（l），由codemetrics插件实时计算，仅作用于光标所在函数。
状态栏里那个 C: 5 M: 85 L: 20 是什么？
这就是 CodeMetrics 插件在当前函数内实时算出的圈复杂度（C）、维护性指数（M）和逻辑行数（L）。它只对光标所在的函数生效，不是整个文件，更不是整个项目。
常见错误现象：光标放在类定义里、文件顶部或空行时显示 N/A；JSX 中混写 HTML 标签导致解析失败；函数体只剩注释或空花括号也会返回 N/A。
- 确保光标落在函数声明/表达式内部（包括
async、箭头函数、method() {}） - 不支持
class整体复杂度，只认函数级作用域 - 若语言是 Python 或 Java 却没反应，检查文件后缀是否为
.py/.java，且未被files.associations错误映射
怎么让高复杂度函数一眼就被揪出来？
默认阈值是 10，超过就变红——但这个数字太宽松。实际项目中，6 就该警惕，11 必须拆分。
修改方式很简单，在 settings.json 加一行：
"codemetrics.complexityThreshold": 6
重启编辑器或重载窗口后，所有 ≥6 的函数在状态栏都会标红。这不是装饰，是提醒你“这段逻辑已经超出人脑短期记忆负荷”。
- 别调成 3 或 4——那会误伤正常分支逻辑（比如带
if-else if-else的状态机） - 阈值设低 ≠ 更严格，而是把“需要人工复查”的范围收得更准
- 如果某函数始终卡在 7–9 之间，大概率说明它本该被拆成两个职责清晰的函数
整个项目有多少个“危险函数”？别靠肉眼扫
CodeMetrics 不提供项目级汇总，这时候得切到命令面板：Ctrl+Shift+P → 输入 Code Metrics: Analyze current file。
它会在侧边栏列出当前文件所有函数的 C 值，按降序排好。你可以快速定位最高那个，点它直接跳转到对应函数开头。
- 别指望它分析
node_modules或dist目录——它压根不进这些文件夹 - 如果想批量看多个文件，得手动逐个打开再触发分析；没有“全工作区扫描”按钮
- 输出里
M（维护性指数）低于 65 的函数，基本等于告诉你：“测试覆盖率再高也难保不出错”
为什么不用 vscode-counter 看“代码行数”来反推复杂度？
因为它是纯文本计数器：数换行符，不分语言、不跳过 JSON/MD/lock 文件、不识别注释或空行。一个 yarn.lock 就能拉高总数上万行，完全失真。
真正影响可维护性的，从来不是总行数，而是单个函数里条件分支、循环嵌套、异常处理的组合密度。
-
Project Statistics可以补位：它能按后缀分类统计code lines/comment lines/blank lines，适合评估整体健康度 - 但如果你盯着
Lines插件的状态栏数字琢磨“这模块是不是太胖了”，那方向就偏了 - 圈复杂度必须基于 AST 解析，不是字符串匹配——这点连 ESLint 的
complexity规则都比它准，只是没那么轻量
真正的难点不在装插件，而在接受一个事实：状态栏突然变红，不是插件出了问题，是你写的那段逻辑，已经超出了安全认知边界。
