VSCode中ESLint插件生效需确认本地已安装eslint（运行npx eslint --version验证）、配置文件（如.eslintrc.cjs）存在且格式正确、禁用冲突格式化器（如Prettier）、启用editor.codeActionsOnSave而非废弃的autoFixOnSave，并确保插件为Microsoft官方版且状态栏显示“ESLint is running”。
确认 ESLint 插件是否真正在项目中生效
VSCode 的 ESLint 插件只是“调度器”，不负责实际执行；真正干活的是你项目 node_modules/.bin/eslint 里的二进制文件。如果没装，插件连 eslint --version 都跑不起来。
- 在终端进入项目根目录，运行
npx eslint --version，有输出才说明已正确安装 - 检查
package.json中devDependencies是否包含eslint和你的自定义格式化插件（如@myorg/eslint-plugin-foo） - 若用 pnpm，确认
node_modules/@myorg/eslint-plugin-foo真实存在，且未因 hoist 失效 -
.eslintrc.cjs必须是 CommonJS 格式（不能用 .json），否则无法require自定义插件
检查 VSCode 是否同时启用了多个格式化器
冲突最常见于保存时多个插件抢着改同一行：ESLint auto-fix、Prettier、Vetur、甚至 VSCode 内置 HTML 格式器都在监听 editor.formatOnSave。
- 打开
.vscode/settings.json，确认只启用一个格式化器："editor.defaultFormatter": "esbenp.prettier-vscode" - 显式关闭其他干扰项：
"html.format.enable": false、"vetur.format.enable": false、"eslint.format.enable": false - 禁用
eslint.autoFixOnSave（该配置已废弃，但旧设置可能残留）；改用editor.codeActionsOnSave控制 ESLint 仅做校验 - 检查 workspace 设置是否被 user 级设置覆盖——新成员常在此翻车
验证 ESLint 配置是否剥离了格式职责
只要 .eslintrc.cjs 里还留着 "semi"、"quotes"、"indent" 这类规则，它就还在和 Prettier 抢地盘，波浪线必然反复闪。
-
extends数组中，"prettier"必须放在最后一项，否则前面的 preset（如plugin:vue/recommended或plugin:node/recommended）会把它覆盖掉 - 删掉所有手动写的格式类 rule，比如
"semi": ["error", "always"]—— 留着就是埋雷 - 加一条
"prettier/prettier": "error"，让 ESLint 把 Prettier 的格式问题也标出来，但不再自己修 - 确保没混用
eslint-config-prettier和eslint-plugin-prettier的旧版配置方式，二者定位不同：前者关规则，后者转错误
用 code --disable-extensions 快速定位冲突源
别猜哪个插件有问题，先验证是不是插件惹的祸。90% 的“越修越乱”问题，靠这一步就能锁定罪魁。
- 终端执行
code --disable-extensions启动干净环境，观察保存/格式化是否恢复正常 - 若恢复，说明必是插件冲突；接着用
Ctrl+Shift+P→Developer: Start Extension Bisect，按提示点“是/否”复现问题，3–5 轮即可缩到 1–2 个嫌疑插件 - 顺手打开开发者工具（
Ctrl+Shift+I），看 Console 是否刷出Extension host terminated unexpectedly或Command 'xxx' is already registered - 运行
Developer: Show Running Extensions，确认语言服务归属——比如.vue文件该由 Volar 还是 Vetur 解析，不能两个都注册
