eslint与prettier必须搭配使用：eslint管逻辑与风格，prettier管格式；需用eslint-config-prettier消冲突、vscode启用prettier为默认formatter；javascript booster靠灯泡手动重构；vue项目vetur（vue2）与volar（vue3）不可混用；react refactor支持选中片段渐进升级。
ESLint + Prettier 组合必须配齐
不装这两个，谈可维护性就是空谈。ESLint 负责逻辑正确性和风格约束（比如 no-unused-vars、no-console），Prettier 负责格式统一（缩进、引号、换行等）。它们分工明确，但规则容易打架——比如 ESLint 的 quotes 和 Prettier 的 singleQuote 冲突。
实操建议：
- 项目根目录必须有
.eslintrc.js（或.eslintrc.json）和.prettierrc - 在 ESLint 配置中
extends加上'prettier'，它会自动关闭所有与 Prettier 冲突的规则 - VSCode 设置里关掉
prettier.eslintIntegration（新版已废弃），改用eslint-config-prettier插件来桥接 -
"editor.formatOnSave": true和"editor.defaultFormatter": "esbenp.prettier-vscode"必须启用，否则保存不生效
JavaScript Booster 重构操作要手动触发
这个插件不是“后台运行”，而是靠光标位置 + 左侧灯泡（?）驱动。它不自动改代码，但能在你写完一行后立刻提供安全、语义无损的转换选项——比如把 var 改成 const，把普通函数转成箭头函数，把 if-else 压成三元表达式。
常见错误现象：
- 灯泡不出现 → 检查文件是否是
.js后缀，且没被.prettierignore或.eslintignore排除 - 选项灰掉 → 当前光标所在位置不满足转换条件（例如函数体为空、变量未被赋值）
- 转换后格式错乱 → 确保 Prettier 已设为默认 formatter，否则 Booster 不会调用格式化
它不替代 ESLint，而是补足“人想改但懒得动”的那部分：安全、局部、即时。
Vetur / Volar 对 Vue 项目不可混用
Vue 2 项目用 Vetur，Vue 3（尤其带 <script setup></script>）必须用 Volar。两者同时启用会导致语法高亮失效、跳转错乱、类型提示消失——这不是 bug，是设计冲突。
使用场景差异：
-
Vetur：支持.vue文件模板校验、style区域 CSS 补全，但对 TS 类型推导弱 -
Volar：深度集成 TypeScript，能准确识别defineProps和defineEmits类型，但需要 VSCode 1.67+ 且禁用 Vetur - 若项目含 Vue 2 和 Vue 3 混合模块，按主版本选插件，次要版本模块单独处理（如用
vue-language-features降级支持）
React Refactor 适合渐进式组件升级
它不是一键重写整个项目，而是聚焦「当前选中片段」：右键选一段 JSX，就能提取为新组件、把类组件转成函数组件、把内联样式抽成 CSS Module。这种粒度控制，避免了全自动迁移带来的副作用风险。
容易踩的坑：
- 提取组件时，插件不会自动处理 props 类型声明 → 若用 TypeScript，需手动补
interface或Props类型 - 转换类组件时，
componentDidMount会转成useEffect(() => {}, [])，但不会帮你拆分依赖数组 → 需人工核对 - 不支持自定义 Hook 的智能识别 → 比如把
useState+useEffect组合抽成 Hook，得靠人判断
真正影响可维护性的，从来不是工具多强大，而是你能否在不破坏上下文的前提下，精准干预某一段代码。这些插件只负责“降低干预门槛”，剩下的判断还得你自己来。
