VSCode插件助力前端代码质量保障-VSCode-PHP中文网

vscode插件本身不直接保障代码质量，真正起作用的是eslint、prettier等工具链，插件仅作为桥梁；装了插件≠自动规范，关键在配置是否生效、规则是否匹配项目需求；eslint没报错需先确认eslint.validate是否启用并覆盖对应语言，自动修复失效需检查editor.codeactionsonsave粒度及与prettier规则冲突，eslint.config.js与.eslintrc.js互斥，优先使用前者且不可共存。

vscode插件助力前端代码质量保障

VSCode 插件本身不直接保障代码质量，真正起作用的是插件背后集成的工具链（如 ESLint、Prettier），而插件只是把它们“接进编辑器”的桥梁。装了插件 ≠ 代码自动变规范，关键在配置是否生效、规则是否匹配项目实际需求。

ESLint 插件没报错？先确认 `eslint.validate` 是否启用

常见现象：安装了 ESLint 插件，但代码里写 const unused = 123 却没标黄、没提示“no-unused-vars”。这不是插件坏了，而是它根本没被激活去检查当前文件类型。

eslint.validate 默认只检查 javascript 和 javascriptreact，如果你用的是 .ts 或 .vue 文件，必须显式加上：["javascript","typescript","vue"]
TypeScript 项目还要确保已安装 eslint-plugin-vue 或 @typescript-eslint/eslint-plugin，否则即使配置了 typescript，规则也加载不了
工作区设置优先级高于用户设置，如果项目根目录有 .vscode/settings.json，它可能覆盖了你全局配的 eslint.validate

保存时自动修复失效？检查 `editor.codeActionsOnSave` 的粒度

很多人配了 "source.fixAll.eslint": true，但保存后依然不修分号、不统一引号——问题常出在“谁有权决定要不要修”。

PigX UI 前端开发

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

下载

该配置只对当前语言模式生效，比如你在 .vue 文件里编辑 <script></script> 区块，语言模式是 vue，但 ESLint 默认不响应 vue 模式下的 fix 请求，需额外加："source.fixAll": true 或明确写 "source.fixAll.vue": true
如果同时开了 Prettier，且两者规则冲突（比如 Prettier 要单引号、ESLint 要双引号），fixAll 可能静默失败，控制台会打印 ESLint: Failed to load config "prettier" 类错误，得靠 eslint-config-prettier 关掉 ESLint 的格式类规则
某些规则不可自动修复（如 no-alert），ESLint 不会报错，但也不会修——不是 bug，是设计如此

`eslint.config.js` 与 `.eslintrc.js` 共存时谁生效？

ESLint v9+ 推荐 flat config（即 eslint.config.js），但很多老项目还在用 .eslintrc.js。二者不会合并，而是互斥：ESLint 优先找 eslint.config.js，找到了就完全忽略 .eslintrc.* 文件。

VSCode ESLint 插件默认支持两种格式，但不自动识别哪个该用——它依赖你本地安装的 ESLint 版本行为
运行 npx eslint --print-config src/index.js 可看到实际生效的配置来源路径，这是判断当前用的是哪个配置文件的最可靠方式
混合使用极易导致规则“看似配置了却不起作用”，尤其当团队成员 ESLint 版本不一致时（v8 vs v9），建议统一升级并只保留一种格式

最容易被忽略的点：ESLint 插件的“实时检查”依赖于 VSCode 的文件监听机制，而它对符号链接（symlink）目录、网络挂载盘、WSL 路径中的某些场景支持不稳定；如果项目放在 /mnt/c/... 下，偶尔会出现规则不触发的情况，换到 WSL 原生路径或本地磁盘可解。这不是配置问题，是编辑器底层限制。