eslint + prettier 协同配置易卡顿，因二者同时监听 onsave 触发重分析导致资源争抢：eslint 默认键入即轻量 lint，若未忽略 node_modules 等目录；prettier 若启用 formatonsave 且未禁用其他格式化器，会与 eslint 的 fixall 冲突，引发两次并行格式化。
VSCode 本身不直接优化 JavaScript 执行速度，但插件组合能显著降低编辑时的感知卡顿、提升补全准确率、减少保存/切换时的延迟——这正是“极致流畅感”的真实来源。关键不在装得多，而在删得准、配得稳、协同得严。
为什么 ESLint + Prettier 协同配置容易卡住 JS 文件？
常见现象是：打开一个 .js 文件后光标响应迟滞、输入几秒才出补全、保存时界面短暂冻结。这不是单个插件的问题，而是多个插件同时监听 onSave 并触发重分析导致的资源争抢。
-
eslint插件默认在每次键入后做轻量 lint，若项目含大量node_modules或未配置eslint.ignorePath，会扫描无关目录 -
prettier-vscode若设为"editor.formatOnSave": true且未禁用其他格式化器，可能和 ESLint 的source.fixAll.eslint冲突，造成两次格式化流水线并行 - 解决路径：在工作区
settings.json中显式关闭冗余行为："eslint.format.enable": false（让 Prettier 独占格式化），并确保"editor.defaultFormatter": "esbenp.prettier-vscode"唯一生效 - 额外建议：在项目根目录加
.eslintignore，写入dist/、build/、node_modules/，避免 lint 过程扫描构建产物
JSX 补全慢？检查 Emmet 和 Volar/Vue Language Features 是否打架
React 开发中，输入 div 回车不出 JSX 标签、rfc 不生成函数组件片段，大概率是语言服务冲突。VSCode 对 .jsx 和 .tsx 的语言识别依赖插件注册顺序和 files.associations 配置。
- 确认
"files.associations"中未将*.js错误映射为typescript或javascriptreact—— 这会导致 JS 文件被当作 JSX 解析，拖慢基础 JS 补全 - Volar（Vue）和 @volar/vue-language-features 若启用，会劫持所有
.js文件的语言模式，除非你明确配置"volar.disableLanguages": ["javascript"] - Emmet 在 JSX 中需手动启用：
"emmet.includeLanguages": { "javascriptreact": "javascript" }，否则div.tab回车不会展开 - 验证方式：打开任意
.js文件，看右下角状态栏显示的是JavaScript还是JavaScript React；如果不是预期语言，用快捷键Ctrl+Shift+P→Change Language Mode临时切回
代码跳转失效、类型提示飘红？Language Server 启动失败才是真凶
点击函数名按 F12 跳不到定义、useState 提示 “cannot find name”，表面是插件没装，实则是 TypeScript Server（TSServer）启动失败或被插件干扰。
- VSCode 内置的 TS 支持依赖
tsserver进程，而ESLint、Volar、Tabnine都可能 fork 自己的 TS 实例，导致内存溢出或端口占用 - 优先禁用非必要 AI 补全插件（如 Tabnine/Copilot）测试：它们常开启完整 AST 分析，对中大型 JS 项目（尤其含
types目录）极易拖垮 TSServer - 在设置中开启
"typescript.preferences.includePackageJsonAutoImports": "auto"，避免手动 import 时反复触发类型重解析 - 终极排查命令：
Ctrl+Shift+P→Developer: Toggle Developer Tools→ Console 标签页，搜索tsserver或error，看是否有Cannot read property 'getProgram' of undefined类报错
真正影响 JS 开发流畅度的，从来不是插件功能多寡，而是每个插件是否明确知道自己该管哪一段生命周期、该放哪一类事件、该让哪条语言通道独占控制权。删掉一个冲突插件，有时比装十个新插件更立竿见影。
