ESLint插件必须配合项目级配置，因其本身无内置规则，需通过.eslintrc.js等文件启用规则；与Prettier冲突时应使用eslint-config-prettier禁用重复格式规则，并确保Prettier为默认格式化器；复杂度检查须启用complexity规则而非仅依赖状态栏插件。
ESLint 是当前 VS Code 插件市场中事实标准的 JavaScript/TypeScript 代码质量检查工具，没有替代品能覆盖它在规则灵活性、框架适配性、CI 集成和生态协同上的综合能力。
为什么 ESLint 插件必须配合项目级配置？
VS Code 的 dbaeumer.vscode-eslint 插件本身不带任何规则——它只是把本地安装的 ESLint 引擎接入编辑器。如果你只装插件不配 .eslintrc.js 或 eslint.config.js，编辑器里根本不会标红任何问题。
- 必须在项目根目录运行
npm init @eslint/config（或pnpm create @eslint/config）生成配置文件 - 推荐继承
eslint:recommended+ 框架插件（如plugin:react/recommended），避免从零写规则 - 若遇到
Parsing error: Cannot use import statement outside a module，检查parserOptions.ecmaVersion是否设为2022或更高
ESLint 和 Prettier 冲突时怎么破？
冲突本质是职责重叠：ESLint 的 semi、quotes 等格式类规则会和 Prettier 对打。解决方式不是禁用 ESLint 规则，而是用 eslint-config-prettier 把这些规则“关掉”。
- 安装：
npm install eslint-config-prettier --save-dev - 在
extends数组末尾加入eslint-config-prettier，顺序很重要——它必须在所有其他规则之后 - 确保
editor.defaultFormatter设为esbenp.prettier-vscode，否则保存时格式化不会生效 - 如果保存后没反应，先检查
editor.formatOnSave是否为true
复杂度检查别只靠插件状态栏
像 CodeMetrics 这类插件只在状态栏显示当前函数的圈复杂度（C 值），视觉提示快但无约束力；真要卡住高复杂度代码，必须用 ESLint 的 complexity 规则。
- 在
.eslintrc.js中启用："complexity": ["error", {"max": 8}]，超过即报错并阻止保存 - 它对箭头函数、async 函数、IIFE 全部有效，但对 class 内未命名方法可能漏检（需确保有明确函数声明）
- 注意和
max-depth、max-params是独立规则，得分别开启，三者共同构成函数可读性基线 - 若项目含大量第三方脚本（如
vendor/目录），建议用overrides排除，避免误报拖慢编辑器
真正卡质量的点不在插件装没装，而在规则是否进配置、是否进 CI、是否被团队强制执行。状态栏红一下就改，和保存直接失败，心理压力差一个数量级。
