eslint与prettier需精准协同：在.eslintrc.js中添加extends: ['prettier']关闭格式冲突规则，editor.defaultformatter设为esbenp.prettier-vscode，禁用eslint的quotes/semi/indent等格式类规则，仅保留逻辑与安全检查。
装对插件，JS代码写出来就自带「专业感」——不是靠排版或注释堆砌，而是变量声明更严谨、函数写法更现代、错误在敲下第一行时就被标红。关键不在多，而在精准协同。
ESLint + Prettier 怎么配才不打架
常见错误现象是保存后代码被反复格式化、引号变来变去、分号忽有忽无。根本原因是两个工具职责重叠但配置没对齐。
- 必须在
.eslintrc.js中加extends: ['prettier']，否则 ESLint 会按自己规则报错，Prettier 又按另一套格式化 -
editor.defaultFormatter必须设为esbenp.prettier-vscode，不能留空或指向其他 formatter - 禁用 ESLint 对格式类规则的检查：比如
quotes、semi、indent这些要交给 Prettier 管，ESLint 只管逻辑和安全（如no-unused-vars、no-console）
JavaScript Booster 能自动重构哪些代码
它不是“一键美化”，而是聚焦高频重构场景，且只在光标落在具体语句上时触发，避免误操作。
- 把
var str = 'xxx'→const str = 'xxx'（判断是否重新赋值） - 把
function foo() {}→const foo = () => {}（自动处理this和参数简化） - 把
if (x) { return a } else { return b }→return x ? a : b（仅当分支都含return才出现该选项） - 把
'hello ' + name + '!'→`hello ${name}!`（识别字符串拼接且变量不多于 3 个）
为什么 Live Server 比 Open in Browser 更适合 JS 开发
核心差异不是“能不能打开浏览器”，而是“改完 JS 后要不要手动刷新”。
- Live Server 启动的是真实 HTTP 服务，支持
fetch、localStorage、module加载等完整运行环境；Open in Browser 是file://协议，跨域、模块导入直接失败 - 修改 JS 文件保存后，Live Server 自动注入热重载脚本，页面 DOM 不重置，状态保留；Open in Browser 每次都是全新加载
- 调试时断点能稳定命中：Live Server 下 Chrome DevTools 的 Sources 面板显示的是真实文件路径；
file://下常显示blob:或乱码路径
真正容易被忽略的是：所有这些插件的协同效果，依赖于你是否把 .eslintrc.js 和 .prettierrc 放在项目根目录。放错位置（比如只放在子文件夹里），ESLint 就找不到规则，Prettier 就按默认配置跑，Booster 的推断也会失准——工具链一旦脱节，专业感就立刻垮掉。
