ESLint与Prettier协同失效是代码质量失控的起点：需配置eslint.workingDirectories适配monorepo，用eslint-config-prettier关闭冲突规则，区分eslint修复与prettier格式化动作。
ESLint 和 Prettier 不是“装了就完事”的工具，它们的协同失效才是前端项目代码质量失控的真正起点。
ESLint 配置文件不生效的常见原因
VSCode 的 ESLint 插件默认只检查当前打开的文件是否在 eslint.config.js（或旧式 .eslintrc.js）所在目录及其子目录下。如果项目结构是 monorepo，比如 packages/foo/ 里有独立的 eslint.config.js，但 VSCode 没配置工作区路径，插件就会退回到全局或父级配置，导致规则不匹配。
- 必须在 VSCode 设置中显式添加
eslint.workingDirectories，例如："eslint.workingDirectories": ["./", "./packages/*"]
-
eslint.validate已被弃用（v9+），改用eslint.lintTask.enable和语言标识列表控制校验范围 - 若使用 TypeScript，需确保
parserOptions.project指向正确的tsconfig.json，否则类型相关规则（如@typescript-eslint/no-unused-vars）不会触发
Prettier 与 ESLint 冲突时的修复顺序
冲突不是配置错误，而是职责重叠：ESLint 的 quotes、semi 等格式类规则和 Prettier 的输出互相打架。解决的关键不是“关掉谁”，而是让 ESLint 放弃格式话语权。
PigX UI 前端开发
下载
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
- 安装
eslint-config-prettier并在extends中靠后引入，它会自动关闭所有与 Prettier 冲突的规则 - 不要手动在
rules里设"quotes": "off"—— 这种写法容易漏项，且升级 ESLint 后新增的格式规则仍可能冲突 - 验证是否生效：运行
npx eslint --print-config path/to/file.js，检查输出中对应规则是否为"off"
保存时自动修复的边界条件
editor.codeActionsOnSave 看似方便，但默认只对 ESLint 可修复的问题起作用，且不包含 Prettier 格式化 —— 它们是两个独立动作。
立即学习“前端免费学习笔记（深入）”；
- 要同时触发两者，需分别配置：
"editor.codeActionsOnSave": { "source.fixAll.eslint": true },<br>"editor.formatOnSave": true - 注意顺序：先 ESLint 修复逻辑问题（如变量未声明），再 Prettier 统一格式，否则格式化可能破坏 ESLint 的修复上下文
- 某些规则（如
no-console）不可自动修复，只会标红；而prettier/prettier错误必须由 Prettier 自己处理，ESLint 插件无法 fix
真正卡住团队的，从来不是插件没装，而是 eslint.config.js 里一行 extends: ['prettier'] 没加，或者 settings.json 里漏了 eslint.workingDirectories —— 这些细节不验证，所有规则都只是摆设。
