JavaScript性能优化关键在脚本加载时机与执行策略：避免head中同步加载大JS；用defer（DOM就绪后顺序执行）或async（独立脚本立即执行）；requestIdleCallback用于低优先级任务并需timeRemaining()校验；scroll/resize事件须节流/防抖，推荐IntersectionObserver和CSS contain替代。
JavaScript 本身不会自动优化页面性能，关键在于你如何写、何时执行、是否阻塞渲染——多数卡顿和白屏问题都源于脚本加载和执行时机失控。
避免在 <head> 中同步加载大体积 JS
浏览器解析 HTML 时遇到 <script> 标签会暂停 DOM 构建，直到脚本下载、编译、执行完成。把重型逻辑（比如图表库、富文本编辑器）放 <head> 里，等于主动给首屏按了暂停键。
- 用
defer：适用于依赖 DOM 但不依赖其他脚本的逻辑，如初始化模块，它会并行下载、延迟到 DOM 解析完毕后按顺序执行 - 用
async：适用于完全独立的脚本（如埋点、广告），下载完立刻执行，不保证顺序，也不等 DOM 就绪 - 绝对避免无属性的
<script src="big-bundle.js"></script>放在<head>
requestIdleCallback 适合做什么
它不是“让 JS 跑得更快”的魔法函数，而是告诉浏览器：“这段逻辑不紧急，请在主线程空闲时再执行”。典型场景是低优先级的 UI 补充（如懒加载非首屏组件、上报非关键行为日志）。
- 别用它处理用户交互响应（比如点击后的状态更新），会有明显延迟
- 必须配合
timeRemaining()判断剩余空闲时间，防止超时阻塞下一帧 - 注意兼容性：IE 完全不支持，Safari 直到 iOS 16.4 才支持，生产环境建议降级为
setTimeout+ 时间切片
频繁触发的事件（如 scroll、resize）必须节流或防抖
滚动一次可能触发几十次 scroll 事件，如果每次回调里都调用 getBoundingClientRect() 或触发重排（offsetTop、clientWidth 等），CPU 会瞬间拉满。
立即学习“Java免费学习笔记（深入）”；
- 用
throttle（固定频率执行）处理视觉反馈类逻辑，如吸顶导航栏位置计算 - 用
debounce（最后一次触发后延时执行）处理搜索建议、窗口尺寸适配等 - 现代替代方案：监听
IntersectionObserver替代滚动监听做懒加载；用 CSScontain: layout paint减少重排影响范围
真正难的不是知道该用 debounce，而是判断某个函数调用是否真的触发了重排或重绘——这需要打开 Chrome DevTools 的 Rendering 面板，勾选“Paint flashing”和“Layout Shift Regions”，而不是靠猜。
