codemetrics插件仅在光标位于函数体内时实时显示该函数的圈复杂度（c）、维护性指数（m）和逻辑行数（l），不扫描文件或模块；c反映控制流分支数，m低于65需复查，l跳过空行和注释；n/a常见于光标在类声明、空行、jsx混写html或函数体为空时；阈值建议设为6以精准定位需人工复查的函数。
CodeMetrics 插件在 VSCode 中不是“运行一下就出报告”的工具，它只在你光标停在某个函数内部时，实时计算并显示该函数的圈复杂度（C）、维护性指数（M）和逻辑行数（L）。它不扫描整个文件，也不分析类或模块——这点必须先明确，否则你会反复刷新、重载、怀疑安装失败。
状态栏里 C: 5 M: 85 L: 20 是什么，为什么有时显示 N/A
这三值只对当前光标所在的函数体生效：C 是 if/for/while/try/catch/?: 等控制流分支总数；M 综合了复杂度、逻辑行数和注释密度，低于 65 就该人工复查；L 是跳过空行和纯注释的逻辑行数，不是物理行数。
常见 N/A 场景：
- 光标停在类声明、文件顶部、空行或注释行上
- 函数体为空（如
function foo() {}）或只剩注释 - JSX 文件中混写 HTML 标签（如
<div>{x}</div>），导致 AST 解析失败 - 文件后缀未被识别（比如 .jsx 被映射成
files.associations里的其他语言）
确保光标落在 function 声明、箭头函数、async 函数或对象方法（method() {}）的大括号内部，且文件是 .ts、.js、.py 等受支持后缀。
怎么让高复杂度函数一眼被揪出来
默认阈值是 10，但这个数字在真实项目中太宽松。实际建议设为 6：≥6 的函数状态栏变红，提示“已超出人脑短期记忆负荷”。
修改方式很简单，在 settings.json 中加一行：
"codemetrics.complexityThreshold": 6
然后重载窗口（Ctrl+Shift+P → 输入 Developer: Reload Window）。注意：
- 别设成
3或4——会误伤带多个else if的合法状态机 - 阈值调低 ≠ 更严格，而是更准地定位“需要人工复查”的函数
- 如果一个函数长期卡在
7–9，大概率说明它本该拆成两个职责清晰的函数
想看整个文件所有函数的复杂度排序，而不是只盯状态栏
按 Ctrl+Shift+P（Windows/Linux）或 Cmd+Shift+P（macOS），输入 Code Metrics: Analyze current file 并执行。它会在侧边栏列出当前文件中每个函数的 C 值，按降序排列，点击条目可直接跳转到对应函数开头。
这个功能不扫描 node_modules、dist、.git 等目录，也不支持“全工作区批量分析”——它就是个单文件轻量查看器。若需项目级汇总，得靠 ESLint 或 Pylint 配合 CI 流程。
为什么不能只靠 CodeMetrics 守住质量底线
CodeMetrics 是编辑器内实时提示工具，它不报错、不阻断保存、不进 CI。真正能拦截高复杂度函数的，是 ESLint 的 complexity 规则：
- 在
.eslintrc.js中配置："complexity": ["error", {"max": 8}] - 它基于 AST 计算，结果稳定，对箭头函数、IIFE、async 函数都有效
- 但不覆盖 class 内部未命名方法（需显式函数声明）
- 若项目含大量第三方脚本（如
vendor/），建议用overrides排除，避免误报
CodeMetrics 和 ESLint 不是二选一，而是互补：前者帮你边写边调，后者帮你守住交付底线。真正难重构的，从来不是整块代码，而是那些藏在几十行中间、C 值悄悄飙到 8 还能通过测试的函数——它不报错，但每次修改都得重读三遍逻辑。
