17370845950

requestIdleCallback 可在主线程空闲时执行低优先级任务，如埋点上报、预加载，比 setTimeout 更精准，但需兼容 Safari 16.4+；应缓存 DOM 查询结果、避免生产环境 console.log、慎用 JSON.parse(JSON.stringify()) 深拷贝。

用 requestIdleCallback 延迟非关键 JS 任务

浏览器主线程空闲时才执行低优先级逻辑，比如上报埋点、预加载非首屏资源。它比 setTimeout(fn, 0) 更精准，也比 IntersectionObserver 更适合纯计算类任务。

注意：不是所有环境都支持——Safari 直到 16.4 才加入，旧版需降级为 setTimeout + performance.now() 估算剩余帧时间。

• 只传入一个函数，不支持传递参数，需用闭包或 bind
• 回调中调用 executionTime 属性可判断是否超时（didTimeout === true），此时应主动让出控制权
• 避免在回调里触发重排（如读取 offsetHeight），否则可能引发强制同步布局

if ('requestIdleCallback' in window) {
  requestIdleCallback((deadline) => {
    while (deadline.timeRemaining() > 0 && tasks.length > 0) {
      doNextTask();
    }
    if (tasks.length > 0) {
      requestIdleCallback(arguments.callee);
    }
  });
} else {
  setTimeout(processTasks, 0);
}

避免在循环中重复调用 document.getElementById 或 querySelector

每次调用都会触发 DOM 查询，即使目标元素没变。尤其在 for 或 forEach 中反复查同一个 ID，性能损耗明显，且容易被忽略。

典型场景：表格行渲染后批量绑定事件、表单校验遍历字段、动态插入节点后立即取值。

• 把查询结果缓存到变量，复用 const el = document.getElementById('submit-btn')
• 若需查多个同类元素，优先用 querySelectorAll 一次获取 NodeList，再遍历
• 对频繁操作的 DOM 节点，考虑用 DocumentFragment 批量插入，减少重排次数

警惕 console.log 在生产环境未移除

看似无害，但在大量循环或高频回调（如 scroll、mousemove）中输出对象，会隐式触发属性遍历、序列化和 UI 渲染，导致 FPS 下降甚至卡死。

Chrome DevTools 关闭时，console.log 仍会执行（只是不显示），V8 不会自动跳过。

• 构建阶段用 Babel 插件（如 babel-plugin-transform-remove-console）自动删掉 console.*
• 不要依赖 if (process.env.NODE_ENV !== 'production') 手动包裹——容易漏、难维护
• 调试用 debugger 或条件断点更轻量；临时日志建议加开关变量控制

JSON.parse(JSON.stringify(obj)) 深拷贝的替代方案

这个“万能写法”在大数据量下极慢，且会丢失 Date、RegExp、undefined、function 和循环引用，还可能触发内存暴涨。

现代项目中，90% 的深拷贝需求其实只需浅层结构复制，或仅处理 plain object / array。

• 简单场景直接用展开运算符：{...obj} 或 [...arr]
• 需真正深拷贝时，用 structuredClone（Chrome 98+、Firefox 94+、Safari 15.4+ 支持）
• 兼容老版本可用 lodash.cloneDeep，但注意它默认不处理 Map/Set，需额外配置
• 服务端返回数据尽量用 Object.freeze 或不可变库（如 Immer）避免拷贝需求

真正影响加载速度的，往往不是某一行代码多慢，而是几十个“差不多可以”的选择叠加后的延迟。比如一个未缓存的 DOM 查询 + 一个没删的 console.log + 一次意外的深拷贝，在 200 行交互逻辑里同时出现，就足以让首屏交互延迟 300ms 以上。