eslint与prettier需分层协作：eslint专注语义检查（如未定义变量），prettier专管格式（缩进、引号）；通过eslint-config-prettier关闭eslint格式规则，避免冲突，并设vscode“formatonsave”为prettier，确保保存时仅格式化一次。
JavaScript 开发效率卡在手动改代码、反复查文档、格式总不一致？不是 VSCode 不够快，而是插件没配对、没用对。
ESLint + Prettier 怎么协同不打架
装了两个却经常保存后代码被反复格式化、分号忽有忽无，根本原因是规则冲突。ESLint 负责语义检查（比如 undefined 未定义变量），Prettier 只管格式（缩进、换行、引号）。两者必须分层协作：
- 先用
eslint-config-prettier关闭 ESLint 中所有和格式相关的规则（如semi、quotes） - 把 Prettier 设为唯一格式化引擎：设置
"editor.formatOnSave": true，并指定默认格式化工具为esbenp.prettier-vscode - ESLint 仍保留语法/逻辑检查能力，比如
no-unused-vars或react-hooks/exhaustive-deps，这些 Prettier 压根不处理
常见错误是直接让 ESLint 自己格式化——它会按自己规则重排，再触发 Prettier 再排一遍，导致光标乱跳、编辑器卡顿。
Quokka.js 实时运行别只当“玩具”
很多人装了 Quokka 就写个 console.log(1+1) 看结果，其实它真正价值在于验证片段逻辑、绕过构建流程快速试错：
- 在
.js文件里任意位置写表达式，比如arr.filter(x => x > 5)，右侧立刻显示过滤结果 - 支持
it()/describe()语法，可直接写小段测试断言，不用开 Jest 环境 - 对异步操作友好：写
await fetch('/api').then(r => r.json())，Quokka 会等 Promise resolve 后显示结果 - 注意：不要在 Quokka 区域里写副作用代码（比如
localStorage.setItem），它会高频重执行，可能污染真实环境
JavaScript Booster 的重构灯泡为什么有时不亮
JavaScript Booster 的黄色灯泡只在「语义明确、安全可转换」的上下文中激活。不是所有代码都能一键重构，它背后做了作用域分析和副作用判断：
- 函数体为空或只含简单表达式（如
return a + b）→ 支持转箭头函数；含this、arguments或yield→ 灯泡不出现 -
if语句必须是完整块结构（有{}），且分支内无return/throw→ 才提供Replace with ?:选项 - 变量声明需满足「单一赋值点」条件：比如
let x; x = 10;和let x = 10;都能拆分，但let x = 1; x = 2;不会触发Split into declaration and initialization
它不靠正则匹配，而是解析 AST，所以看似相似的代码，灯泡亮或不亮，反映的是实际可重构性，不是插件故障。
snippets 插件怎么避免补全冲突
同时装了 JavaScript (ES6) code snippets 和 ES7+ React/Redux/React-Native snippets，输入 imr 却展开成 import { } from '' 而不是 import React from 'react'，这是补全优先级问题：
- VSCode 默认按插件安装顺序决定 snippet 权重，后装的往往覆盖先装的
- 在设置里搜
editor.snippetSuggestions，设为"top"可让 snippet 始终出现在建议列表顶部，减少误触其他补全 - 更稳妥的做法：禁用冗余 snippet 插件，只留一个主力（比如专注 React 开发就只留 ES7+ 插件），再用
javascript.preferences.suggest.autoImports控制自动导入行为 - 自定义 snippet 优先级更高：在
~/Library/Application Support/Code/User/snippets/javascript.json（macOS）里加一条"imr": { "prefix": "imr", "body": ["import React from 'react';"] }，就能强制覆盖
真正影响效率的，从来不是插件数量，而是每个插件是否在你敲下 Tab 的瞬间，给出你真正想要的那一行。
