Bottom-Up视图按Self Time降序聚合函数，直接暴露CPU瓶颈；关注Self Time（自身耗时）、Total Time（含子调用）、Activity（执行类别）；通过Callers/Callees定位调用链，右键“Reveal in Flame Chart”关联用户行为；典型热点包括重复匿名函数、原生方法高Self Time、自定义函数低Callee调用数等。
在 Chrome DevTools 的 Performance 面板中，Bottom-Up（自底向上）视图是定位真正“耗时根源”的关键工具。它不按调用顺序罗列，而是按函数自身执行时间（Self Time）从高到低聚合，把真正吃掉 CPU 的底层函数直接顶到前面——哪怕它被调用了几百次、嵌套很深，只要单次或累计“自己干的活”最多，就会优先暴露出来。
看懂 Bottom-Up 表格的三列核心字段
打开 Performance 面板 → 录制一段操作 → 停止后切换到 Bottom-Up 标签，重点关注：
- Self Time：该函数**自身执行耗时**（不含子调用），单位毫秒。这是最关键的指标，值越大，说明这个函数体内的逻辑越重（比如大循环、复杂计算、正则匹配）。
- Total Time：该函数及其所有子调用的总耗时。如果 Self Time 小但 Total Time 大，说明它是个“中转站”，真正慢在它调用的下层函数。
- Activity：函数所属的执行类别，如 Script Evaluation、Rendering、Layout 等。JS 函数通常显示为 “(program)” 或具体函数名，带 “Script” 前缀。
快速定位 JS 瓶颈函数的操作步骤
不是从顶部找，而是从底部“钻”：
Wjs Uploading Video
下载
将一个或多个视频上传至YouTube。当用户想“上传到YouTube”“发YouTube”“批量上传”“upload to YouTube”“post videos to YouTube”或发布到YouTube时使用此技能。
- 先按 Self Time 降序排列（默认就是），直接看排第一、第二的函数名。如果是匿名函数，注意看它的调用位置（如 “foo.js:42”）；如果是内置方法（如
Array.prototype.map），说明你代码里某处 map 回调写得过重。 - 点击目标函数行，在右侧的 “Callers” 区域查看谁调用了它；在 “Callees” 区域查看它又调用了谁。这样就能确认它是独立热点，还是某个父函数反复触发它的结果。
- 右键该函数 → “Reveal in Flame Chart”，跳转到火焰图对应位置，观察它是否集中在某一帧爆发（比如滚动/动画帧中突然卡顿），从而关联用户行为。
典型 JS 热点函数特征与应对方向
以下几种情况在 Bottom-Up 中非常醒目，可立即判断问题类型：
- 大量重复的匿名函数（如 “(anonymous) @ utils.js:88” 占比极高）：大概率是事件监听器、定时器或渲染循环中未节流/防抖的回调，每次触发都新建函数并执行重逻辑。
-
原生数组方法名 + 高 Self Time（如
Array.prototype.forEach、String.prototype.replace）：说明你传入的回调或正则本身开销大，不是方法慢，是你写的逻辑慢。 -
自定义函数名 + 高 Self Time + 低 Callee 调用数：函数内部存在未优化的算法，比如 O(n²) 循环、深克隆、频繁 DOM 查询（
document.querySelectorAll）等。 -
多个不同函数但共享同一调用路径（如都来自
renderList→getItemProps→ 各种计算）：瓶颈不在单个函数，而在整个渲染链路的数据处理环节，适合用 memoization 或计算缓存优化。
配合代码验证的小技巧
找到可疑函数后，别急着改，先加一行性能标记验证：
console.time('heavyCalc');
const result = heavyCalc(data);
console.timeEnd('heavyCalc'); // 看控制台输出是否和 Bottom-Up 的 Self Time 接近
如果接近，说明定位准确；如果不符，可能是 DevTools 采样精度或异步调度干扰，可尝试多次录制取平均值。
