性能监控是断点的放大器，先定位问题时段，再用断点验证；通过performance面板分析长任务、内存泄漏和渲染卡顿；在可疑函数设条件断点或debugger；结合console.time和performance.mark细分耗时；启用异常断点与preserve log快速回溯崩溃。
性能监控不是断点的替代品，而是它的放大器——它帮你先锁定“哪里可能出问题”，再用断点精准切入验证。
用 Performance 面板圈定可疑时段
页面崩溃前往往伴随长任务、强制同步布局或内存陡增。打开 Chrome DevTools 的 Performance 面板，点击录制按钮（●），复现操作后停止。重点看三处：
- 主线程火焰图：找持续 >50ms 的红色/橙色长条，右键“Zoom to selection”聚焦，看里面执行了哪些函数
- 内存曲线：勾选 Memory 复选框，若 JS Heap 持续上涨不回落，说明有内存泄漏，崩溃常发生在 GC 压力峰值时
- FPS 和渲染帧：出现大片红色卡顿帧，且下方标记为 “Layout” 或 “Recalculate Style”，说明 DOM 操作过重，可能触发隐式同步计算导致阻塞
在可疑函数入口打条件断点 + debugger
从 Performance 找到高频调用或耗时异常的函数名（比如 renderList、updateState），回到 Sources 面板定位源码：
- 在函数第一行设行断点，右键 → Edit breakpoint → 输入条件，如 items.length > 1000，避免在小数据量时误停
- 或直接在函数体开头插入 debugger;，确保 DevTools 已开启，运行即中断
- 进入断点后，切换到 Memory 面板 → Take heap snapshot，对比前后快照，查是否有意外保留的大对象引用
结合 console.time 和 performance.mark 定位子环节
如果崩溃发生在某个复合操作中（如一次完整表单提交），不要只盯整体耗时。在关键节点打标：
- performance.mark('submit-start');
- performance.mark('encrypt-done');
- performance.mark('send-end');
- 最后用 performance.measure('total', 'submit-start', 'send-end'); 查总耗时，并在 Console 中执行 performance.getEntriesByType('measure') 查各段是否某一段突然飙升
崩溃后快速回溯：启用异常断点与 Preserve log
有些崩溃一闪而过，控制台来不及显示错误。这时要提前布防：
- 在 Sources 面板右侧 Breakpoints 区域，勾选 Catch exceptions（所有异常）或 Caught exceptions（仅捕获但未处理的）
- 在 Console 面板右上角三点菜单中开启 Preserve log，防止页面刷新或崩溃后日志清空
- 若崩溃由 Promise 链中断引发，务必勾选 Uncaught promise rejections，它能捕获未 await 也未 catch 的异步错误
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
