VSCode代码质量检查依赖三大扩展：ESLint、Prettier和EditorConfig；需正确配置settings.json启用自动修复与格式化，并确保工作区为项目根目录以加载配置文件。
VSCode 本身不自带代码质量检查能力，真正起作用的是扩展——但装错或配置不当，反而会让 eslint 报错不显示、prettier 格式化失效、保存时没自动修复，甚至和项目原有规则冲突。
哪些扩展是 linting 和格式化的事实标准？
只推荐三个核心扩展，其他多数是它们的包装或冗余：
-
ESLint（由dbaeumer.vscode-eslint提供）：负责静态分析、规则校验、问题定位。必须配合项目中已有的.eslintrc.cjs或eslint.config.js才能生效，单独安装不会“自动变好” -
Prettier（esbenp.prettier-vscode）：专注格式化，不检查逻辑错误。它和eslint不是替代关系，而是协作关系——先用eslint --fix修规则类问题，再用prettier统一换行缩进空格 -
EditorConfig for VS Code（editorconfig.editorconfig）：读取项目根目录的.editorconfig，统一基础编辑器行为（如indent_size、end_of_line），避免团队成员编辑器设置差异导致的格式抖动
别装 “JavaScript (ES6) code snippets” 或 “Beautify” 这类老式格式化工具——它们和 prettier 冲突，且不支持现代配置协议。
为什么保存后没自动修复？关键在 settings.json 配置
VSCode 默认关闭自动修复，需手动启用，并明确指定触发时机和工具链顺序：
{
"editor.codeActionsOnSave": {
"source.fixAll.eslint": true,
"source.fixAll.preprocess": false
},
"editor.formatOnSave": true,
"editor.defaultFormatter": "esbenp.prettier-vscode",
"eslint.validate": ["javascript", "typescript", "vue"],
"prettier.requireConfig": true
}
注意几个易错点：
-
"prettier.requireConfig": true表示：只有项目存在prettier.config.js或.prettierrc时才启用格式化，否则静默跳过——防止污染没有约定的临时文件 -
"source.fixAll.eslint"是 ESLint 的专属开关，不是"source.fixAll"通用开关；后者对prettier无效 - 如果项目同时用
eslint和prettier，必须确保eslint-config-prettier已安装并禁用所有与格式相关的 ESLint 规则，否则会反复“修-改-再报错”
如何判断当前文件是否被正确 lint？
看 VSCode 窗口右下角状态栏：
- 显示
ESLint图标 ✅ + 无报错 → 配置加载成功，规则运行中 - 显示
ESLint图标 ❌ 或灰色 → 扩展未识别到配置文件，打开命令面板（Ctrl+Shift+P）运行ESLint: Show Output Channel查看具体错误，常见原因是node_modules/.bin/eslint不在PATH，或工作区启用了错误的 Node 版本 - 光标悬停在报错行上没提示 → 检查
eslint.validate是否包含当前语言（例如 Vue 文件需显式加入"vue"）
别依赖“有没有红色波浪线”来判断——有些规则（如 no-console）默认是 warn 级别，只在问题面板显示，不会标红。
最常被忽略的一点：所有配置都以工作区（workspace）为边界。打开一个子文件夹（比如只开 src/），eslint 就找不到项目根下的 package.json 和配置文件——必须用 VSCode 打开整个 Git 仓库根目录。
