ESLint插件没反应，大概率是本地eslint未安装；VSCode的ESLint扩展仅调用项目中的eslint可执行文件，若node_modules/.bin/eslint不存在则静默失效，需在项目根目录执行npm install eslint --save-dev并确认配置文件位置及格式正确。
ESLint 插件没反应，大概率是本地 eslint 没装上
VSCode 的 ESLint 扩展（dbaeumer.vscode-eslint）本身不带检查器，它只负责调用你项目里的 eslint 可执行文件。如果 node_modules/.bin/eslint 不存在，插件会静默失效——你看到的波浪线可能来自 VSCode 自带的 JavaScript 校验器，和你的 .eslintrc.js 完全无关。
确认方式很简单：在 VSCode 集成终端里运行 npx eslint --version。如果报错或无输出，说明本地没装，或者装在了错误位置。
- 必须在项目根目录执行
npm install eslint --save-dev（或yarn add eslint --dev） - 若用 TypeScript，额外安装
@typescript-eslint/parser和@typescript-eslint/eslint-plugin - Monorepo 项目需确保
eslint和插件都装在 workspace 根，或当前 package 的node_modules下 - 不要依赖全局
npm install -g eslint，企业环境通常禁用全局安装
配置文件被忽略？检查文件名和加载路径
ESLint 扩展默认只读取工作区根目录下的配置文件，且对文件名敏感。常见失效场景是：你写了 .eslintrc.cjs，但 VSCode 实际加载的是 eslint.config.js（v8.53+ 推荐格式），或反之。
打开命令面板（Ctrl+Shift+P），运行 ESLint: Show Output Channel，看日志里是否出现 Using configuration from /path/to/your/.eslintrc.js。如果没有，说明配置没被识别。
- 优先使用
eslint.config.js（ESLint v8.53+ 默认查找顺序首位） - 旧项目可继续用
.eslintrc.js或.eslintrc.cjs，但确保导出语法匹配文件后缀（.cjs里不能用export default） -
package.json中的eslintConfig字段也有效，但不如独立文件清晰，不推荐用于企业级规范统一 - 子目录下放配置文件无效——VSCode 不递归查找，必须放在打开的工作区根目录
保存时自动修复不生效，可能是 Prettier 在抢活
很多团队同时装了 ESLint 和 Prettier 插件，结果 Ctrl+S 时代码被两次格式化：ESLint 先 fix 一遍（比如补分号），Prettier 紧接着重排缩进、引号、换行，最终格式混乱甚至触发新错误。
根本解法不是禁用 Prettier，而是明确分工：让 ESLint 负责规则校验 + 可修复项（如空格、分号），Prettier 仅处理纯格式（如单双引号、括号换行）。
- 关闭 Prettier 的自动格式化：
"editor.formatOnSave": false - 启用 ESLint 保存修复：
"editor.codeActionsOnSave": {"source.fixAll.eslint": true} - 若必须共存，加
eslint-config-prettier关闭 ESLint 中与 Prettier 冲突的规则 - 注意：
no-console、no-unused-vars这类逻辑规则无法自动修复，只会标红——别误以为配置失败
企业级统一配置，靠 .vscode/settings.json 而不是个人设置
靠每个开发者手动配 settings.json 无法保证一致性。企业级落地的关键，是把关键配置写进项目根目录的 .vscode/settings.json，并提交到 Git。
这个文件会被 VSCode 自动读取（无需用户手动开启），且优先级高于用户级设置，能强制覆盖本地干扰项。
- 必须包含：
"eslint.enable": true、"editor.codeActionsOnSave": {"source.fixAll.eslint": true} - 显式关闭内置校验：
"javascript.validate.enable": false、"typescript.preferences.includePackageJsonAutoImports": "auto" - 指定包管理器：
"eslint.packageManager": "pnpm"（按项目实际填npm/yarn/pnpm） - 避免写
"editor.formatOnSave": true—— 格式化策略应由 ESLint 或 Prettier 统一控制，而非编辑器原生行为
真正容易被忽略的点是：配置文件本身没问题，但 VSCode 没用对 Python 解释器或 Node.js 版本——右下角状态栏的解释器和 Node 版本必须和 eslint、pylint 实际运行环境一致，否则所有配置都是空中楼阁。
