不推荐使用for-in遍历数组，因为它会遍历包括继承属性在内的所有可枚举属性、遍历顺序不确定、索引为字符串类型，应改用for、foreach或for-of循环。
进阶开发者不是靠插件数量取胜，而是用得准、配得稳、踩坑少。真正拉开效率差距的，往往就那三五个插件 + 两三条写 JS 的硬习惯。
eslint + prettier 配合出问题？先看 eslint-config-prettier 是否启用
常见错误现象是保存后代码格式“越修越乱”：Prettier 把分号删了，ESLint 又标红提示“Missing semicolon”。这不是配置冲突，而是规则没对齐。
- 必须安装
eslint-config-prettier插件（不是prettier本体） - 在
.eslintrc.js的extends数组末尾加上'prettier'，顺序不能颠倒 -
settings.json中禁用 ESLint 自动修复：设"eslint.enable": true，但不要开"eslint.autoFixOnSave"——让 Prettier 负责格式，ESLint 只管逻辑 - 如果项目用 TypeScript，额外加
plugin:@typescript-eslint/recommended，且确保@typescript-eslint/eslint-plugin版本与 TS 版本兼容（比如 TS 5.4+ 对应 eslint-plugin v6.0+）
Live Server 启动报错 ERR_CONNECTION_REFUSED？检查端口和协议
不是插件坏了，而是本地服务被占或协议不匹配。尤其在 Vue/React 脚手架项目里，直接右键 Open with Live Server 往往失败。
- Live Server 默认用
http://，但现代前端框架（如 Vite）默认启动https://或绑定到特定端口（如:5173） - 不要依赖右键菜单，改用终端手动启动：
npx serve -s -p 3000（静态资源）或npm run dev（框架命令） - 若坚持用 Live Server，需在
settings.json中指定端口："liveServer.settings.port": 3001，并确认该端口未被占用（lsof -i :3001on macOS/Linux） - 跨域调试时，Live Server 不处理代理，得靠
vite.config.ts的server.proxy或 Webpack DevServer 的devServer.proxy
JavaScript and TypeScript Nightly 为什么比默认语言支持更稳？
VS Code 内置的 JS 支持基于旧版 TypeScript 服务，对新语法（如 const { data } = await fetch(...) 的顶层 await、模块块作用域）识别滞后，导致类型提示缺失或误报。
-
JavaScript and TypeScript Nightly是微软官方发布的预发布版语言服务器，每天更新，提前支持 TC39 Stage 3+ 提案 - 启用后，JS 文件的
Go to Definition更准，Find All References不漏全局变量，IntelliSense能识别 JSDoc 中的@typedef和泛型注释 - 注意关闭内置支持：在
settings.json加"javascript.suggest.autoImports": false，避免和 Nightly 的自动导入冲突 - 如果项目用 ESM +
type: "module"，Nightly 会正确解析import.meta.url，而默认支持常报Cannot find name 'import'
写 JS 时容易忽略的三个底层细节
不是语法糖用得多就高级，而是清楚每行执行时 JS 引擎在干什么。
- 避免
for...in遍历数组：它遍历所有可枚举属性（包括原型链上的），用for...of或Array.prototype.forEach更安全 -
===比==快，但更关键的是避免隐式转换陷阱——比如[] == false为true，而[] === false是false - 函数内声明变量优先用
const，哪怕后面要重新赋值对象属性；let仅用于需要重绑定的场景（如循环计数器），不用var——它的函数作用域和变量提升在模块化开发中已无存在必要
插件装得再全，也救不了对 JS 执行模型模糊的人；配置调得再细，也盖不住没搞清 Promise 和 async/await 底层差异的代码。真正的进阶，从看清那一行 console.log 真正何时执行开始。
