运行时性能分析需体现指标意识、排查路径与落地动作：明确fps50ms等量化标准，按复现→录制→聚焦→下钻闭环定位根因，并给出绑定场景的优化方案及轻量监控措施。
运行时性能分析不是只说“我用过 Chrome DevTools”，而是要体现你有指标意识、有排查路径、有落地动作。重点不在工具罗列，而在“发现问题→定位根因→验证修复”的闭环能力。
明确关键性能指标，不凭感觉判断
面试官想听你是否建立量化标准。不能只说“页面卡”，要说清楚卡在哪一环：
- FPS 低于 50 持续 2 秒以上，说明渲染主线程压力大；
- Long Task（>50ms）频繁出现，大概率是 JS 执行阻塞；
- 内存占用持续增长且页面跳转后不回落，提示可能有闭包未释放或事件监听未解绑；
- 重排（Layout）/重绘（Paint）次数突增，常和高频 DOM 修改或强制同步布局有关。
按场景拆解排查路径，突出逻辑性
遇到卡顿，不是打开 Performance 面板随便录一段，而是有策略地复现和聚焦：
- 先复现：固定操作路径（如“点击按钮→列表滚动→快速切换 Tab”），确保问题可稳定触发；
- 再录制：在 Performance 面板勾选 JS Profile、Screenshots、Memory，录制 10–15 秒典型操作；
- 后聚焦：看 Flame Chart 中的长条（JS 执行）、锯齿状 Layout/Paint（渲染抖动）、堆内存曲线是否阶梯上升；
- 最后下钻：点击可疑长任务，看 Bottom-Up 标签里耗时最高的函数，结合代码确认是否做了冗余计算、重复渲染或未节流的 scroll 处理。
给出具体优化动作，避免空泛术语
说到优化，别只提“用防抖”“做懒加载”，要绑定上下文：
- 比如“搜索框输入卡顿”：把实时请求改成 输入停顿 300ms 后触发 debounce 请求，同时加 loading 状态禁用重复提交；
- 比如“长列表滚动掉帧”：改用 虚拟滚动（vue-virtual-scroller 或 react-window），只渲染可视区域 5 行 + 缓冲区，DOM 节点从 5000 个降到约 20 个；
- 比如“页面关闭后内存不释放”：检查 useEffect / mounted 中添加的 addEventListener 是否配对 removeEventListener，闭包中引用的 DOM 节点是否手动置为 null。
补充轻量监控意识，体现工程化思维
高分回答会延伸一步：如何让性能问题“提前暴露”，而不是等用户反馈？
- 在路由离开前采集 window.performance.memory.usedJSHeapSize，对比进入时涨幅超 20MB 就上报；
- 用 MutationObserver 监听 body 下新增节点数，单次操作新增超 100 个就记录 warning；
- 对高频回调（resize、scroll、input）自动包裹 throttle（30fps 对应 ~33ms），通过 SDK 统一管控。
