CodeMetrics插件可实时显示光标所在函数的圈复杂度（C）、维护性指数（M）和逻辑行数（L），C反映控制流分支总数，M低于65需警惕，L为跳过空行和注释的逻辑行数；阈值设为6时≥6的函数状态栏标红，精准定位需人工复查的高风险函数。
直接装 CodeMetrics 就能快速定位高风险函数，不用配 LSP、不依赖项目构建、不扫描 node_modules——它只看你光标停在哪，实时算当前函数的圈复杂度（C）、维护性指数（M）和逻辑行数（L）。
状态栏里 C: 5 M: 85 L: 20 是什么？
这是 CodeMetrics 在你光标所在函数内实时计算出的三个关键指标：C 是圈复杂度，反映 if/for/while/try/catch/?: 等控制流分支总数；M 是维护性指数，综合了复杂度、行数和注释密度，低于 65 就该警惕；L 是逻辑行数（跳过空行和纯注释），不是物理换行数。
常见错误现象：
- 光标放在类声明、文件顶部或空行时显示
N/A - JSX 中混写 HTML 标签（如
<div>{foo}</div>）导致解析失败 - 函数体只剩
{}或全是注释，也会返回N/A
确保光标落在函数声明/表达式内部（包括 async、箭头函数、method() {}），且文件后缀正确（.ts、.js、.py 等）。
怎么让高复杂度函数一眼就被揪出来？
默认阈值是 10，但实际项目中，6 就该人工复查，11 必须拆分。修改方式很简单，在 settings.json 加一行：
"codemetrics.complexityThreshold": 6
重载窗口后，所有 ≥6 的函数在状态栏都会标红。这不是装饰，是提醒你“这段逻辑已经超出人脑短期记忆负荷”。
别调成 3 或 4——那会误伤正常分支逻辑（比如带 if-else if-else 的状态机）。阈值设低 ≠ 更严格，而是把“需要人工复查”的范围收得更准。如果某函数始终卡在 7–9 之间，大概率说明它本该被拆成两个职责清晰的函数。
为什么不用 ESLint 的 complexity 规则代替？
ESLint 的 complexity 规则是项目级静态检查，需要配置、运行、看问题面板，无法像 CodeMetrics 那样在编辑器右下角实时反馈。两者不是互斥，而是互补：
-
CodeMetrics适合边写边调：改完一段逻辑，立刻看C值有没有跳变 -
ESLint适合守住底线：在 CI 或保存时强制拦截超限函数 -
ESLint能检测嵌套深度、参数数量等维度，CodeMetrics只专注函数粒度的C/M/L
如果你只装一个工具来快速识别“哪里最可能出 bug”，CodeMetrics 是更轻、更快、更直观的选择。
真正难重构的从来不是整块代码，而是那些藏在几十行中间、C 值悄悄飙到 8 的函数——它不会报错，测试也能过，但每次修改都得重读三遍逻辑。盯住状态栏那个红色数字，比翻几百行问题面板更有效。
