直接看performance面板main轨道上≥50ms的连续色块即可锁定拖慢页面的代码块，这是最直观可靠的起点；需找黄色或红色长条、悬停查看耗时、点击展开调用栈定位源码行号，并结合network和memory面板排除外部干扰。

直接看 Performance 面板 Main 轨道上 ≥50ms 的连续色块，就能锁定拖慢页面的代码块——这是最直观、最可靠的起点。

盯住 Main 轨道里的“长条”

录制操作后，在时间轴下方的 Main 线程轨道中，找那些明显拉长的黄色或红色区块。Chrome 会自动标记为 “Long Task”，悬停显示具体耗时（比如 “86.3 ms”）。只要宽度 ≥50ms，就说明这段 JS 占用了主线程太久，用户操作会被卡住。

• 单个孤立长条：可能是某次重渲染、复杂计算或同步 DOM 操作
• 密集排列多个长条（尤其每帧都出现）：说明主线程持续过载，不是单点问题，而是整体逻辑压力过大
• 顶部 FPS 曲线同步掉红：进一步验证渲染被阻塞，和长任务强相关

点开看调用栈，找到你的源码行

点击任意一个长任务色块，底部 Summary 面板会立刻展开细节：

• 看 “Self Time”：数值大，说明函数自身逻辑重（比如循环遍历万级数组），不是子调用拖累的
• 展开 “Call Stack”：从上到下逐层查看调用链，最终会落到你写的 .js 文件和具体行号
• 前提是开启 Source Maps：构建时保留映射，否则看到的是压缩后的 bundle 行号

结合 Network 和 Memory 辅助判断

有些“慢”不是 JS 执行慢，而是被外部因素拖累：

• Network 面板里某个请求长时间处于浅色（waiting）：DNS、TCP 或服务器响应慢，JS 可能卡在 await fetch() 上
• Memory 面板拍两个堆快照对比：如果某类对象持续增长且不释放，JS 逻辑可能在不断创建却没清理（比如监听器没移除、缓存没清空）
• Performance 面板里 Layout / Recalculate Style 占比高：说明 JS 触发了频繁样式读写，导致强制同步布局

验证改动是否真有效

改完代码别只看“感觉变快了”，要回归 DevTools 验证：

• 重新录制相同操作，对比长任务数量和总时长是否下降
• 关注 Scripting 时间占比是否降低，FPS 是否更平稳
• 如果瓶颈在第三方库（比如 markdown-it 解析慢），可尝试加 loading 提示、分块解析或服务端预渲染