vscode插件本身不直接构建企业级项目，但通过正确配置eslint+prettier自动修复、统一格式化工具、解决多根工作区规则路径问题及避免规则冲突，可显著降低构建门槛、统一团队行为并保障ci/cd一致性。
VSCode 插件本身不直接“构建”企业级项目，但能显著降低构建门槛、减少配置错误、统一团队行为——关键在于选对插件、配对规则、避开常见断点。
ESLint + Prettier 组合必须启用自动修复
很多团队装了插件却没打开 editor.formatOnSave 或没配 eslint --fix 触发时机，导致代码风格仍靠人工肉眼检查。实际项目中，未启用自动修复的 ESLint 几乎等于摆设。
- 必须在
settings.json中设置："editor.formatOnSave": true且"editor.defaultFormatter": "esbenp.prettier-vscode" - 确保
package.json的scripts包含"lint": "eslint . --ext .js,.jsx --fix"，CI 流水线可直接复用 - 注意：Prettier 和 ESLint 规则冲突时，优先用
eslint-config-prettier关闭 ESLint 的格式类规则（如indent、quotes），只保留逻辑类规则（如no-unused-vars）
JavaScript Booster 能安全重构但不替代 Code Review
它提供的 Convert to const、Replace with ?: 等操作确实能秒级优化代码，但它的“安全”仅限于语法层面——比如不会判断 var 改成 const 后是否影响后续赋值，也不会校验箭头函数改写后 this 绑定是否出错。
- 适合在单文件、无副作用、已通过单元测试的模块中使用
- 禁用场景：类方法体内、React Class Component 的生命周期函数、含
eval或with的旧代码块 - 快捷键
Ctrl+.（Windows）触发灯泡菜单比鼠标点击更稳，避免误触其他命令
多文件夹工作区里插件行为会受路径层级干扰
当用 .code-workspace 同时加载 frontend、backend、shared 三个文件夹时，ESLint 默认只读取最外层根目录的 .eslintrc.js，而各子项目可能有自己独立的规则配置——这时会出现“前端报错、后端不报”的现象。
- 解决方式：在每个子项目根目录放独立的
.eslintrc.js，并确保 VSCode 的eslint.workingDirectories配置为：[{"mode": "auto"}] - 验证是否生效：打开任意一个 JS 文件，执行命令
ESLint: Show Output Channel，看日志里解析的是哪个路径下的配置文件 - 注意：Prettier 不支持多配置自动切换，所有子项目必须共用同一份
.prettierrc，否则格式化行为不一致
真正卡住企业级落地的，往往不是插件功能强不强，而是配置是否随项目结构动态适配、是否能在 CI/CD 中复现本地行为、以及团队成员是否理解每条规则背后的约束条件。
