页面卡顿、白屏、内存暴涨等运行时性能问题，本质是主线程被长任务阻塞、样式重算频繁、垃圾回收密集或内存泄漏所致，需通过Performance和Memory面板定位瓶颈，而非仅查报错。
运行时性能问题本身不报错，但会引发卡顿、白屏、内存暴涨等现象，背后往往藏着未被捕获的错误或低效逻辑。排查重点不是“找报错”，而是“找瓶颈”。
看 Performance 面板定位长任务
打开 Chrome DevTools → Performance → 点击录制 → 操作页面 → 停止。重点关注：
- 主线程中持续超过 50ms 的红色/橙色长条（Long Task），说明 JS 执行太重
- 频繁出现的 Layout / Recalculate Styles，说明样式计算开销大（比如读写 offsetHeight 后立刻改 class）
- GC（Garbage Collection）密集出现，提示内存分配过快或存在泄漏
查内存泄漏和异常增长
切换到 Memory 面板，用“堆快照（Heap Snapshot）”对比操作前后：
- 重复操作后，Detached DOM 节点数量持续增加 → 可能是事件监听器没卸载或闭包引用了 DOM
- 大量相同构造函数实例（如 MyComponent）堆积 → 组件销毁逻辑缺失或缓存未清理
- 全局变量意外增长（window.xxx 或 this.xxx）→ 检查是否漏写了 var/let，导致变量挂到全局
抓异步错误和静默失败
很多性能退化源于异步链中断或 Promise 拒绝未处理：
- 在 Console 中开启 “Pause on caught exceptions” 和 “Uncaught exceptions”，观察是否有被吞掉的错误
- 检查 fetch、setTimeout、addEventListener 是否有未加 .catch() 的 Promise，或未绑定 this 的回调
- 用 performance.mark() + performance.measure() 打点关键路径，确认耗时是否集中在某段逻辑（比如数据解析、渲染循环）
验证类型与数据结构合理性
弱类型容易掩盖性能隐患：
- 接口返回的 id 字段本该是 number，却收到字符串 "123"，后续做数组索引或 JSON.stringify 时隐式转换拖慢速度
- 把大对象直接塞进 React state 或 Vue reactive，触发全量响应式追踪，可用 Object.freeze 或结构拆分优化
- 用 for...in 遍历数组（而非 for 或 for...of），多出原型链遍历开销；用 includes 查找大数组，应改用 Set.has()
