VSCode ESLint插件_前端代码规范检查与自动修复-VSCode-PHP中文网

vscode eslint 插件默认不自动修复，需配置 editor.codeactionsonsave 启用 source.fixall.eslint；禁用 editor.formatonsave 避免冲突；eslint.validate 需包含文件类型（如 "vue"）；仅带?图标的规则可修复（如 semi、quotes），no-console 等不可修复。

vscode eslint插件_前端代码规范检查与自动修复

VSCode 的 ESLint 插件默认不会自动修复代码，必须显式配置 editor.codeActionsOnSave 才能触发保存即修复 —— 这是绝大多数人配不成功的第一原因。

为什么保存后没自动修复？检查这三项配置

常见现象是：ESLint 能标红错误，但 Ctrl+S 后毫无反应。根本原因通常是以下任一配置缺失或冲突：

editor.codeActionsOnSave 没启用 source.fixAll.eslint（不是 source.fixAll）
editor.formatOnSave 设为 true，与 ESLint 自动修复抢夺控制权，导致静默失败
eslint.validate 未包含当前文件类型（比如 Vue 文件漏了 "vue"，HTML 中的内联 JS 就不会被检查）

正确写法示例（放入 settings.json）：

{
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
  },
  "editor.formatOnSave": false,
  "eslint.validate": ["javascript", "typescript", "vue", "html"]
}

哪些规则能自动修复？看规则文档里的扳手图标

ESLint 官网每条规则页右上角有图标：? 表示可修复，⚠️ 表示仅警告，❌ 表示不可修复。别指望它帮你删掉 console.log 或改 == 成 === —— 这些都得手动处理。

典型可修复规则包括：

PigX UI 前端开发

PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。

下载

semi：补/删分号
quotes：统一单引号/双引号
comma-dangle：调整尾逗号
indent：重排缩进（空格数、Tab 使用）
no-trailing-spaces：删行尾空格

不可修复的典型规则：no-console、no-unused-vars、no-undef、no-eval —— 它们涉及语义判断，ESLint 不会擅自删代码。

Vue 单文件中 script / template / style 修复能力不同

ESLint 默认只校验 <script></script> 块里的 JS/TS 逻辑。template 和 style 需额外插件支持：

<template></template>：靠 eslint-plugin-vue 提供的规则（如 vue/mustache-interpolation-spacing），部分可修复；但 HTML 结构类问题（如属性顺序、自闭合标签）ESLint 无能为力，得靠 Prettier 或 Vetur
<style></style>：ESLint 不处理 CSS，需用 stylelint；prettier 可格式化 CSS，但不属于 ESLint 范畴
若你发现 .vue 文件里 template 报错却不修复，先确认 eslint.options.extensions 包含 ".vue"，且 extends 中启用了 plugin:vue/recommended 类规则集

多人协作时，.eslintrc.js 里 rules 写法影响修复结果

规则优先级从高到低：项目 .eslintrc.js → 插件 preset（如 plugin:vue/essential）→ eslint:recommended。容易踩的坑：

在 rules 里写 "semi": "off"，会导致该规则彻底关闭，连修复入口都没了
写成 "semi": ["error", "always"] 才启用可修复逻辑；"warn" 级别下，VSCode 默认不触发修复（除非你手动右键选“快速修复”）
Vue 项目常用 vue/multi-word-component-names，它不可修复 —— 一旦报错，只能手动改组件名，别等自动修

真正关键的不是“有没有规则”，而是规则值是否为 ["error", ...] 且该规则本身支持修复。否则保存时就只是划红线，不会动代码。