Performance面板中通过Main轨道和事件标记可分析事件全流程耗时，需录制单一可复现操作，定位Event任务块并检查是否超50ms、嵌套调用及阻塞；再结合Summary面板看Script/Layout/Paint等阶段占比，最后用Call Stack下钻至源码行级定位瓶颈。

直接看 Performance 面板里的 Main 轨道和事件标记，就能看清事件从触发到执行完毕的完整耗时分布——关键不是总时间，而是各阶段拆解是否合理。

抓准事件源头：从用户操作开始录制

打开 Performance 面板 → 点击录制按钮（●）→ 执行一次明确操作（如点击按钮、输入文字、滚动页面）→ 停止。Chrome 会自动把这次交互关联到对应事件（click、input、scroll 等），并在时间轴顶部标出事件名和起始位置。确保操作单一、可复现，避免多动作混叠干扰判断。

定位事件处理链：主线程里找“事件回调”块

Main 轨道中，每个事件都会生成一个以 “Event: click” 或 “Event: input” 开头的任务块，宽度代表整体耗时。鼠标悬停可看到具体事件类型、触发时间、持续毫秒数。重点观察：

• 该块是否超过 50ms → 判定为长任务，需下钻
• 块内是否包含多个嵌套调用（如 dispatch → handler → setState → render）
• 是否存在明显空隙或阻塞（比如 JS 执行完后卡住，接着才 Layout/Paint）

拆解耗时构成：看 Summary 面板的阶段占比

点击任一事件任务块，在下方 Summary 面板中会列出本次执行的详细阶段耗时：

• Script Evaluation：JS 逻辑执行时间（含你的事件处理器、状态更新、diff）
• Layout：浏览器计算布局（常因读写 DOM 交替触发，如 getBoundingClientRect() 后立刻改 style）
• Paint：绘制图层内容（通常不占大头，但频繁重绘会拉低 FPS）
• Composite Layers：图层合成（一般很快，若耗时高，说明层管理不合理）

如果 Script Evaluation 占比超 70%，说明瓶颈在 JS；若 Layout 突然飙升，大概率是强制同步布局导致。

下钻到代码行级：Call Stack + Source Maps

在 Call Tree 或 Bottom-up 标签页中，按 “Total Time” 排序，找到耗时最高的函数（比如 handleSearch、onInputChange）。展开其调用栈，逐层查看：

• 是否调用了未节流的 resize/input 回调
• 是否在循环中反复访问 offsetTop、clientWidth 等触发 Layout 的属性
• 是否同步渲染了大量 DOM 节点（尤其 React 中未 memo 或未虚拟化列表）
• 是否有第三方 SDK 在事件中执行重型初始化（检查 “Third-party script execution” 分类）

只要开启了 Source Maps，最终能定位到你源码中的具体文件和行号，左侧还会显示该行实际执行耗时。