应先用Chrome DevTools等工具定位真实性能瓶颈，聚焦长任务、Layout/Paint及JS调用栈；再针对性优化高频路径、关键渲染链路和事件监听器；善用原生API、轻量结构与懒加载，并持续验证效果。
明确性能瓶颈再动手重构
盲目优化代码往往事倍功半。先用浏览器开发者工具（如 Chrome DevTools 的 Performance 面板）录制真实用户操作，重点关注 长任务（Long Tasks）、频繁的 Layout / Paint、以及高耗时的 JS Call Stack。也可用 console.time() 和 console.timeEnd() 快速定位某段逻辑耗时，但仅作初步筛查，不能替代真实场景采样。
聚焦高频执行路径和关键渲染节点
性能问题常集中在三类地方：事件监听器（如 scroll、input）、组件更新周期（React/Vue 的 render 或 patch）、以及首屏关键渲染链路（如数据解析、模板生成）。重构时优先处理这些位置：
- 给节流/防抖加合理 delay（例如 scroll 用
requestIdleCallback或throttle(16ms)） - 避免在 render 中做深克隆、正则全局匹配、或遍历大数组
- 把非关键计算（如日志拼接、非紧急状态派生）移到微任务后或空闲时段
用更轻量的数据结构和原生 API 替代框架糖
框架抽象带来便利也隐含开销。当性能敏感时，可局部“降级”：
- 用
for循环代替map/filter/reduce（尤其数组超千项） - 用
document.querySelector替代封装过深的选择器库 - 用
Object.is()或浅比较代替深 equal 工具函数 - 字符串拼接优先用模板字面量或数组
join，少用+=（V8 已优化，但旧环境仍有差异）
拆分与懒加载不是万能解，但要会选时机
代码分割（Code Splitting）和动态 import 能减少初始包体积，但不直接提升运行时速度。真正影响运行时的是执行逻辑的粒度：
- 把大对象初始化拆成按需创建（如复杂配置 parser 不在模块顶层 new）
- 对 DOM 操作密集区，用
DocumentFragment批量插入，减少重排 - 动画帧内只做必要更新，把计算结果缓存到变量，避免重复取
getBoundingClientRect等
不复杂但容易忽略。每次改完跑一遍 Performance 录制，对比 FPS、总耗时、内存增长，比凭感觉更可靠。
