codemetrics插件仅在光标位于函数体内时实时计算并显示该函数的圈复杂度（c）、维护性指数（m）和逻辑行数（l），不扫描文件或项目；n/a表示光标不在有效函数体中；通过命令“code metrics: analyze current file”可查看当前文件所有函数c值降序列表；阈值建议设为6以精准定位需人工复查的函数。
CodeMetrics 插件不是“项目级扫描器”，它只在光标停在函数体内时才计算该函数的圈复杂度（C）、维护性指数（M）和逻辑行数（L）。想靠它一键列出所有高风险函数？不行。但用对方式，它能精准帮你揪出最该拆分的那几个。
为什么光标一离开函数就显示 N/A？
这是正常行为，不是插件坏了。CodeMetrics 的设计就是函数级、实时、按需计算：
- 只响应光标落在
function声明体、const fn = () => {}、async function或对象方法method() {}的大括号内部 - 类声明、空行、注释行、JSX 混写 HTML（如
<div>{x}</div>）都会导致 AST 解析失败，返回N/A - 文件后缀必须被正确识别：.ts/.js/.py/.java 才触发分析；若 .jsx 被
files.associations映射成其他语言，也会失效
怎么快速定位当前文件里最复杂的函数？
别手动挨个把光标挪过去。直接调用命令面板：
- 按
Ctrl+Shift+P（Windows/Linux）或Cmd+Shift+P（macOS） - 输入
Code Metrics: Analyze current file并执行 - 侧边栏会列出当前文件所有函数的
C值，按降序排列；点击任意条目，光标自动跳转到对应函数开头
注意：它不进 node_modules、dist、.git，也不支持跨文件聚合——这就是它的边界。
阈值设成多少才算真正有用？
默认 "codemetrics.complexityThreshold": 10 几乎没用。真实项目中，6 就该警惕，11 必须拆分：
- 在
settings.json中加一行："codemetrics.complexityThreshold": 6 - 重载窗口（
Ctrl+Shift+P→Developer: Reload Window） - 状态栏变红 ≠ 写错了，而是提示“这段逻辑已超出人脑短期记忆负荷”
- 设成 3 或 4 会误伤合法状态机（比如带多个
else if的分支）；设成 6 是为了把“需要人工复查”的范围收得更准
CodeMetrics 不能替代 ESLint 的 complexity 规则
它只提示，不拦截。如果你要守住质量底线，必须配 ESLint：
- 在
.eslintrc.js中启用："complexity": ["error", {"max": 8}] - 保存时自动报错，CI 流程可强制阻断提交
- 它基于 AST 分析，对箭头函数、async 函数、IIFE 全部有效；但 class 内部未命名方法需显式声明为函数才能被识别
- 若项目含大量第三方脚本（如
vendor/），建议用overrides排除，避免误报
真正麻烦的从来不是“找不到复杂函数”，而是“找到之后没人动它”。CodeMetrics 给你信号，ESLint 给你约束，缺一不可。
