VSCode需借助插件或语言服务器实现代码复杂度检测：CodeMetrics提供状态栏实时函数级C/M/L值，轻量提示；ESLint complexity规则可拦截超限函数，支持CI集成；Pylint需手动安装配置才生效；vscode-counter不可用于质量评估。
VSCode 本身不提供代码复杂度检测能力，必须依赖插件或语言服务器集成 ESLint、Pylint 等工具才能实现函数级圈复杂度（Cyclomatic Complexity）等指标的实时反馈。
CodeMetrics 插件：状态栏实时显示当前函数的 C/M/L 值
这是最轻量、响应最快的函数级复杂度查看方式，适合日常编码中快速感知逻辑膨胀。它直接在 VSCode 状态栏右下角显示类似 C: 5 M: 85 L: 20 的三元组，分别代表圈复杂度、维护性指数、逻辑行数。
- 仅对光标所在函数生效，不分析类、模块或整个文件；支持 TypeScript/JavaScript/Python/Java/C#，但对 JSX 内嵌 HTML 或语法错误的函数会显示
N/A - 阈值可调：
"codemetrics.complexityThreshold": 10加入settings.json后，超限函数状态栏变红 - 不统计注释/空行，
L是逻辑行（Logical Lines），跳过纯注释和空行，比原始行数更贴近可维护性评估 - 它不做跨函数调用链分析，也不报错或阻断保存，纯提示型——适合“写完瞄一眼”，不适合 CI 或质量门禁
ESLint 配置 complexity 规则：真正能拦截高复杂度函数的方案
如果你需要在保存时就报错、阻止提交，或者统一团队函数复杂度上限，complexity 规则是唯一可靠选择。它由 ESLint 解析 AST 计算，结果稳定、可配置、可集成到 pre-commit 流程中。
- 在
.eslintrc.js中启用："complexity": ["error", {"max": 8}]，函数圈复杂度 >8 就标红并中断保存 - 注意它和
max-depth（嵌套深度）、max-params（参数个数）是独立规则，需分别开启；三者共同构成函数可读性基线 - 对箭头函数、async 函数、IIFE 全部有效，但不覆盖 class 内部未命名方法（需确保方法有明确函数声明）
- 性能影响轻微，但若项目含大量
node_modules外的第三方脚本（如vendor/目录），建议用overrides排除，避免误报
Pylint 检查 Python 函数复杂度：需要显式安装 + 路径配置
Python 用户不能只装 VSCode 的 Pylint 扩展，还必须在当前 Python 环境中安装 pylint 包，并让 VSCode 正确定位到可执行路径，否则 Cyclomatic complexity 类指标根本不会出现。
- 终端运行
pip install pylint（推荐在项目虚拟环境中） - 在
settings.json中至少设置两项："python.linting.pylintEnabled": true和"python.linting.pylintPath": "pylint" - 若 VSCode 无法自动识别虚拟环境中的
pylint，需填绝对路径，例如："${workspaceFolder}/.venv/bin/pylint"（macOS/Linux） - Pylint 默认阈值是 10，可通过
.pylintrc文件修改：max-complexity=8，该值影响C0001类警告输出
别把 vscode-counter 当代码质量工具用
这个插件只是统计换行符数量，vscode-counter 统计结果包含 yarn.lock、package-lock.json、README.md 甚至图片二进制文件里的 \n，完全不可用于质量评估。
- 它不区分语言、不跳过生成文件、不识别注释，
total lines数字毫无工程意义 - 真正需要工作区级汇总，用
Project Statistics：它按后缀分类、自动排除node_modules和.git，还能拆出 code/comment/blank 行 - 如果想导出数据做趋势分析（比如每周复杂度均值），必须用 CLI 工具：
eslint --format json --output-file report.json或pylint --output-format=json，VSCode 插件层不提供结构化导出能力
复杂度数字本身没有绝对好坏，关键看它是否触发你重新审视控制流——比如一个 C: 12 的函数，可能只是漏提了一个提前返回，也可能真需要拆成三个职责清晰的子函数。工具只负责标出“这里可能难改”，怎么改，还得人来判断。
