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，性能损耗明显，且容易被忽略。
典型场景：表格行渲染后批量绑定事件、表单校验遍历字段、动态插入节点后立即取值。
立即学习“Java免费学习笔记（深入）”；
- 把查询结果缓存到变量，复用
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 以上。
