VSCode怎么设置保存时运行代码检查_VSCode如何在保存文件时自动执行Lint校验【攻略】-VSCode-PHP中文网

要实现保存时自动触发 eslint 检查，需配置三个关键开关：安装官方 eslint 插件、启用 "editor.codeactionsonsave": { "source.fixall.eslint": true }、确保项目根目录存在有效 eslint 配置文件（如 .eslintrc.js 或 package.json 中的 eslintconfig）。

vscode怎么设置保存时运行代码检查_vscode如何在保存文件时自动执行lint校验【攻略】

保存时自动触发 ESLint 检查要配哪几个关键开关

VSCode 本身不自动运行 Lint，必须靠插件 + 正确配置协同工作。核心是 eslint 插件 + "editor.codeActionsOnSave" + "eslint.autoFixOnSave"（已弃用）或更现代的 "editor.codeActionsOnSave" 细粒度控制。

常见错误现象：点了保存，控制台没输出、问题没标红、修复没发生——大概率是 editor.codeActionsOnSave 里漏了 source.fixAll.eslint，或者 ESLint 没在当前工作区识别到配置文件（.eslintrc.js 或 package.json 里的 eslintConfig）。

确保已安装官方 eslint 插件（作者：Microsoft），不是其他同名但非官方的
检查项目根目录是否存在有效的 ESLint 配置文件；没有的话，eslint --init 初始化一个

在 VSCode 设置（settings.json）中启用：

"editor.codeActionsOnSave": {
  "source.fixAll.eslint": true
}

如果只想修部分规则（比如不自动改缩进），别开 "source.fixAll"，只开 "source.fixAll.eslint"

为什么改了 settings.json 还是不生效

最常被忽略的是作用域问题：你改的是用户级设置，但项目里有 .vscode/settings.json，它会覆盖全局设置。VSCode 优先读取工作区设置，再 fallback 到用户设置。

另一个典型原因是 ESLint 进程没起来——比如项目没装 eslint 本地依赖（npm install eslint --save-dev），或装了但版本太老（v8+ 才支持 codeActionsOnSave 的细粒度控制）。

打开命令面板（Ctrl+Shift+P），运行 ESLint: Show Output Channel，看有没有报错，例如 Cannot find module 'eslint'
确认 node_modules/.bin/eslint 存在且可执行；若用 pnpm/yarn，需确保插件能正确定位二进制
检查 eslint.options 设置是否误写了 cwd，导致配置文件路径解析失败

TypeScript 文件里 ESLint 不报错也不修复

默认情况下，ESLint 只处理 .js 和 .jsx。TS 文件需要显式告诉 ESLint：“我也要管”。这靠 eslint.parserOptions.project 和正确的 parser（如 @typescript-eslint/parser）配合。

VSCode

避免常见的 VSCode 错误——设置冲突、调试器配置和扩展冲突。

下载

现象包括：TS 中的未使用变量、any 类型、interface 命名等完全不提示——不是插件坏了，是 ESLint 根本没把 .ts 当作目标文件。

确保 eslint-plugin-typescript（即 @typescript-eslint/eslint-plugin）和对应 parser 已安装并配置在 extends 中

在 eslint.config.js 或 .eslintrc.cjs 里加：

"parserOptions": {
  "project": "./tsconfig.json"
}

确认 tsconfig.json 路径正确，且包含 "include" 字段覆盖你的源码目录（否则 parser 会跳过所有文件）
VSCode 设置里别开 "eslint.validate"（v2.4.0+ 已废弃），它会干扰新机制

保存时卡顿或 CPU 爆高

ESLint 在保存时全量校验 + 自动修复，对大文件或复杂规则（比如 complexity、max-lines）可能阻塞编辑器主线程，尤其开启 source.fixAll.eslint 后还叠加 Prettier 格式化。

这不是 bug，是同步执行 lint 导致的天然延迟。解决思路是缩小作用范围、异步化、或分阶段处理。

限制只对特定语言启用：

"editor.codeActionsOnSave": {
  "source.fixAll.eslint": true
},
"[javascript]": {
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
  }
},
"[typescript]": {
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
  }
}

关掉耗性能的规则（如 no-console 一般不用 auto-fix，max-lines-per-function 也不适合保存时修）
避免在 codeActionsOnSave 里同时开 source.fixAll.eslint 和 source.formatDocument，容易冲突；建议只留 ESLint 修逻辑，Prettier 单独用保存格式化

真正麻烦的点在于：ESLint 的 auto-fix 是“尽力而为”，有些规则根本不可修复（比如 no-alert），有些修复后会引入新问题（比如重命名变量但没更新引用）。别指望它 100% 安全，每次保存后仍需肉眼扫一眼改动。