Firefox DevTools 通过 Performance、Inspector 和 Debugger 面板定位事件卡顿根因：查长任务阻塞、强制重排、未节流高频监听器，并验证响应延迟是否≤100ms。
查主线程是否被 JS 长任务占满
用户点击后延迟响应，大概率是主线程正忙于执行某段 JS，来不及处理事件队列。
- 打开 Performance 面板（Ctrl+Shift+E 或 Cmd+Opt+E），录制一次典型点击操作
- 停止后，在瀑布图中找点击时刻对应的红色/黄色长条（>50ms），右键 → “Zoom in” 局部放大
- 展开该长任务的调用栈，重点关注：是否在事件监听器里做了大量计算、DOM 查询（
querySelector）、或反复读写布局属性（offsetTop、getBoundingClientRect()） - 若发现某函数反复出现且耗时高，可右键 → “Blackbox this frame” 临时屏蔽，观察响应是否变快
揪出隐式强制重排（Layout Thrashing）
很多“点不动”其实源于 JS 在同一帧内反复读写样式，浏览器被迫多次同步计算布局。
- 在 Performance 面板录制中，切换到 Markers 标签页，勾选 Layout 和 JavaScript samples
- 查找标为 Forced reflow 的标记，它会直接指向触发重排的 JS 函数
- 常见模式：
el.offsetWidth→ 修改el.style.left→ 又读el.clientHeight→ 再改样式……这类链式操作必须拆开，或改用transform/opacity替代 - 在 Console 中临时插入
console.time('layout');+ 关键代码 +console.timeEnd('layout');，确认单次开销是否超 2–3ms
检查事件监听器是否过度或未节流
滚动、鼠标移动、窗口缩放等高频事件若未做防抖/节流，会瞬间堆积数十个待处理任务。
- 在 Inspector 面板中右键目标元素 → Break on > attribute modifications 或 node removal，观察是否因监听器误触发 DOM 变更而连锁反应
- 在 Debugger 面板中，点击左上角齿轮 → 勾选 “Enable event listener breakpoints”，再点击页面，看哪些监听器被触发、耗时多少
- 特别关注
scroll、mousemove、input监听器：它们是否用了requestAnimationFrame包裹？是否加了{ passive: true }（尤其 touchstart/move）？ - 临时禁用 JS（Debugger 面板右上角 → Disable JavaScript），若点击立刻响应，说明瓶颈就在 JS 事件逻辑里
验证优化效果要对比真实交互帧
别只看平均 FPS，重点看用户操作那一刻的响应间隙（INP）是否缩短。
- 录制前确保开启 Disable HTTP Cache（设置 → 高级设置），避免缓存干扰
- 在 Performance 面板中，找到点击事件触发后的第一个 paint 或 layout 任务之间的空隙——这个间隙就是实际响应延迟，目标应 ≤ 100ms
- 导出两次录制的 JSON（⋮ → Save analysis data），比对 “Input delay” 字段和 主线程闲置时间占比
- 配合 Network 面板看：是否有某个脚本加载完成才绑定监听器？延迟绑定会导致首次点击无响应，需提前注册或用事件委托
