JavaScript性能优化核心是减少冗余计算、避免阻塞、提升引擎可预测性；需警惕循环内重复属性访问、闭包滥用、Array高阶函数隐式开销，善用DevTools精准定位瓶颈，并始终验证优化效果。
JavaScript 性能优化不是靠“写得炫酷”，而是减少不必要的计算、避免意外的阻塞、让引擎更容易预测和优化你的代码。很多看似微小的写法差异，会在高频执行或大数据量场景下放大成明显卡顿或内存泄漏。
避免在循环中重复计算或访问深层属性
每次访问 arr[i].data.items.length 这类嵌套属性，V8 都要逐层查对象属性；如果放在 for 循环里，等于重复做几十上百次相同查找。
常见错误现象：for (let i = 0; i 每次都读 list.length（虽有优化，但非绝对安全）；更危险的是 for (let i = 0; i 。
- 把长度或中间结果缓存到局部变量：
const len = arr.length;、const items = obj.data.items; - 对频繁访问的 DOM 属性（如
element.offsetTop）也建议缓存，避免触发强制同步布局（layout thrashing） - 使用
for...of时注意：它底层调用迭代器，比缓存后的for略慢，但语义清晰；若性能敏感且遍历数组，优先用缓存索引的for
减少闭包捕获与长生命周期引用
闭包本身不慢，但若函数被长期持有（比如绑定到事件、存在定时器、存入全局 Map），它捕获的外层变量就无法被 GC 回收——哪怕
使用场景：组件销毁前忘记清理事件监听器；React 中 useCallback 依赖项写错导致闭包持续持有所有 props；Node.js 中 request 处理函数引用了大 buffer。
- 只传真正需要的值，而不是整个对象：
onClick={() => handler(item.id)}比onClick={() => handler(item)}更安全 - 必要时手动解除引用：
timer = null;、element.removeEventListener(...); - 避免在循环中创建闭包函数（如
for (let i = 0; i i);），改用参数传入或let块级作用域
警惕 Array 方法的隐式开销
map、filter、reduce 写起来简洁，但它们会新建数组、全量遍历、无法中途退出。对大数组或条件提前终止场景，可能比手写 for 慢 2–5 倍。
错误类型示例：arr.filter(x => x > 5).find(x => x % 2 === 0) —— 实际只需找第一个符合条件的偶数，却先建了一个新数组。
- 用
for或for...of替代链式调用，尤其当逻辑含 “找到即停” 或 “只取前 N 个” -
Array.from(new Set(arr))去重比[...new Set(arr)]稍快（少一次展开运算），但更关键的是确认是否真需要数组——有时Set本身就能满足后续查找需求 -
push比concat或展开运算符[...a, ...b]更省内存，后者必须一次性分配合并后大小的空间
用好 Chrome DevTools 定位真实瓶颈
90% 的“我觉得很慢”和实际瓶颈位置并不一致。盲目优化 sort 函数，结果发现卡顿来自每帧都触发的 getBoundingClientRect()。
性能 / 兼容性影响：不同版本 V8 对同一段代码优化策略不同（如内联函数阈值、逃逸分析强度），所以不能只看本地跑分。
- 录制时勾选
Memory和JavaScript samples，重点关注Self Time高的函数 - 用
console.time('label')+console.timeEnd('label')快速验证某段逻辑耗时，但别在生产环境留着 - 注意 “Scripting” 时间占比高 ≠ JS 写得差，可能是频繁的
innerHTML赋值触发了反复解析 HTML，这时应改用document.createElement批量构建
最常被忽略的一点：优化前没确认是否真有性能问题；优化后没验证是否真的变快——尤其跨浏览器、跨设备时，V8、SpiderMonkey、JavaScriptCore 的行为差异会让某些“技巧”失效甚至更慢。
