17370845950

应避免在循环中重复 DOM 查询及渲染阶段同步计算，需缓存查询结果、用 useMemo/computed 缓存计算、分离异步操作，并从链路视角优化叠加开销。

避免在循环中重复计算 DOM 查询

每次调用 document.getElementById、document.querySelector 等方法都会触发浏览器的查找逻辑，如果放在 for 或 while 循环里，性能损耗会随迭代次数线性增长。

• ✅ 正确做法：把查询结果缓存到变量中，循环内复用
• ❌ 错误写法：

  for (let i = 0; i < 100; i++) {
    document.getElementById('list').appendChild(item);
  }

• DOM 查询本身不昂贵，但频繁触发样式计算或重排（如读取 offsetHeight 后又修改样式）会直接引发强制同步布局
• 现代框架（如 React）默认批量更新，但手写 DOM 操作时需格外注意“读-写”混合顺序

慎用 console.log 在生产环境或高频回调中

console.log 不仅输出慢，在某些浏览器（尤其是旧版 Chrome）中还会序列化整个对象，导致意外的内存占用和卡顿。它在 requestAnimationFrame、scroll、input 等高频事件中尤为危险。

• 开发阶段可保留，上线前务必移除或用条件包装：

  if (process.env.NODE_ENV === 'development') {
    console.log('debug:', data);
  }

• 部分调试器（如 VS Code 的 Debugger for Chrome）支持断点条件，比日志更轻量
• 用 performance.mark() + performance.measure() 替代时间打点日志，更精准且无副作用

减少闭包中对外部大对象的隐式引用

闭包会持有其词法作用域中所有变量的引用。若一个函数被长期驻留（如绑定到事件监听器、定时器、Promise 回调），而它又无意中捕获了某个大数组、DOM 树或全局状态对象，就会阻止垃圾回收，造成内存泄漏。

• 检查方式：Chrome DevTools → Memory → Take heap snapshot，筛选 Closure 类型并观察 retainers
• 修复策略：显式清空不需要的引用，例如在事件解绑后置 handler._cache = null
• 常见陷阱：

  function createHandler(data) {
    return function() {
      console.log(data.hugeArray.length); // data 整个被保留
    };
  }

  应改为只提取所需字段：

  const len = data.hugeArray.length;
  return () => console.log(len);

避免在 render 阶段做同步计算或 API 调用

在 React、Vue 等框架的渲染函数或 computed 属性中执行耗时操作（如深克隆、正则匹配长文本、JSON.parse 大字符串），会阻塞主线程，导致掉帧。尤其当这些逻辑未加 memoization 时，每次 re-render 都重复执行。

• ✅ 推荐方案：用 useMemo / computed 缓存结果；将纯计算抽离为独立函数并预处理
• ❌ 危险模式：

  render() {
    const processed = expensiveTransform(this.props.list); // 每次 render 都跑一遍
    return ;
  }

• 注意：JSON.stringify 和 JSON.parse 在大数据量下非常慢，优先考虑结构共享或增量更新
• 异步操作（如 fetch）绝不能出现在渲染路径中，必须提前 resolve 或用 Suspense / loading state 分离

真实项目中最难察觉的性能问题，往往不是某一行代码多慢，而是多个小开销在特定路径上叠加 —— 比如一次 scroll 事件触发了 3 个未节流的 handler，每个都查了一次 DOM、log 了一条信息、又触发了一次未 memoized 的计算。优化要从链路视角切入，而不是只盯着单个函数。