调试与质量 · 运行证据
性能分析Performance Profiling
性能分析会录下一次真实操作，把耗时拆成时间线和函数热点，再用同一场景验证优化是否有效。
录下这次搜索卡顿，看看时间花在哪
这是浏览器里的性能分析工具：左边是发生卡顿的商品搜索，右边会把同一次操作拆成时间线和函数耗时。
第 0 步 · 打开工具先打开 Chrome 开发者工具 → Performance → Record
NOVA MARKET找到你的夏日衣橱
12,000 件商品夏季衬衫输入后卡住 318ms
!
输入后页面短暂失去响应先录下这次卡顿，再决定改哪里
Performance
等待录制准备录制这次搜索操作发生后，时间线会把 318ms 拆开。
录制结果
等待一次可重复的操作录制后会在这里选中最耗时的函数。
Profiling 会拆开一次真实操作的耗时，帮你找到时间究竟花在哪一段；火焰图只是其中一张结果视图。
知识点：从症状走到真实热点
刚才不是凭感觉改列表，而是用同一动作留下可以比较的运行证据。
- 先固定数据、浏览器和操作；否则两次结果不能直接比较。
- 时间线先指出哪一段形成长任务，火焰图再指出 CPU 时间主要花在哪个函数。
- 优化最宽的热点后，用完全相同的搜索复测，确认 318ms 是否真的下降。
什么时候用、怎么用
单页搜索、点击或动画出现卡顿时，用 Profiling 拆开这一次操作；跨服务请求变慢则优先看链路追踪。
- 入口：打开 Chrome DevTools 的 Performance，点击 Record 后重演问题。
- 最短路径：固定场景 → 录制 → 选中长任务 → 找最大热点 → 做最小改动 → 同条件复测。
- 不要只盯 CPU：网络、布局和渲染也可能让页面变慢，要先看时间线的证据。
正反例：同一搜索，只改变优化顺序
目标都是让搜索恢复流畅，差别在于先看运行证据，还是先凭感觉改代码。
同条件复测从 318ms 降到 74ms，证明改动命中了真实热点。
filterItems 仍占最大宽度，搜索卡顿没有解决，只是把时间花在了错误位置。
快速自测
商品搜索偶尔卡住，但你还没有可比较的 profile。第一步该做什么？
继续查证
术语的技术定义和行为以这些一手或权威资料为准。
下一步学
和本知识点经常一起出现的概念。