INP高但Main Thread任务不长，是因为INP衡量交互后主线程连续阻塞总时长（含微任务、同步布局、样式重算等），而非单个长任务；Performance面板易漏掉组合式阻塞，需结合Web Vitals定位、User Timing标记及Rendering/Layout轨道分析隐藏开销。
为什么 INP 高但 Main Thread 任务看起来不长？
INP（Interaction to Next Paint）不是看单个任务耗时，而是看用户交互后，主线程被阻塞导致响应延迟的最差情况。哪怕 task.duration 普遍低于 50ms，只要某次点击触发了一连串连续执行的微任务 + 回调 + 渲染更新（比如 input 事件后紧跟着 requestAnimationFrame + 大量 DOM 更新 + 强制同步布局），就可能把“响应窗口”拖到 200ms 以上——而 Chrome 的 Performance 面板默认只高亮单个 >50ms 的 long task，容易漏掉这种组合式阻塞。
真正要盯的是：交互时间点（event.timestamp）之后、首次渲染完成（Paint 或 Layout）之前，所有连续占用主线程的任务总和。
如何在 Performance 面板里准确定位那个“元凶交互”
别直接拉 Timeline 找红条。先打开录制设置里的 “Screenshots” 和 “Web Vitals”，然后手动复现一次卡顿的交互（比如快速点击搜索框并输入）。录制结束后：
- 在
Web Vitals轨道里找到标为INP的矩形块，右键 →Zoom to INP - 切换到
Main Thread轨道，把时间轴缩放到该 INP 对应的时间窗口（通常会自动对齐） - 找交互事件（
click/input/keydown）图标，往右看它触发的整个调用链：从事件处理函数开始，是否立刻进了setTimeout、Promise.then、requestIdleCallback？有没有意外触发getBoundingClientRect()或offsetHeight导致强制同步布局？
重点不是单个 FunctionCall 有多长，而是这一整段“事件→计算→DOM→样式→布局→绘制”的链条是否被拆散或压缩在 100ms 内完成。
用 User Timing API 主动标记关键路径，绕过面板盲区
Performance 面板对异步链路追踪有限，尤其跨微任务、跨 RAF 的逻辑容易断开。建议在关键交互入口加手动标记：
document.getElementById('search-input').addEventListener('input', (e) => {
performance.mark('inp-start');
// ...你的业务逻辑
renderResults(); // 假设这里触发大量 DOM 更新
performance.mark('inp-end');
performance.measure('inp-duration', 'inp-start', 'inp-end');
});这样在 Performance 面板的 Timings 轨道就能看到真实端到端耗时，且能和下方 Main Thread 的任务堆叠对齐。如果 inp-duration 是 180ms，但 Main Thread 上只有两个 30ms 的任务，说明中间有未被捕获的空闲等待（比如 await 等网络）、或渲染管线被其他 tab / background script 干扰。
常见假象与必须检查的三类隐藏开销
很多团队优化了 long task 却没降 INP，问题常出在这些非 JS 执行阶段：
-
Layout Thrashing：反复读写 DOM（如循环里交替调用
el.offsetWidth和el.style.width），Chrome 不会把它记成一个long task，但每次读都会触发同步布局，累积起来就是 INP 元凶 -
Style Recalculation Storm：CSS 中大量使用
:hover、:nth-child或全局选择器（* {}），一次 class 切换就让引擎重算上千元素样式，这类开销出现在Recalculate Style阶段，不在 JS 任务里 -
Compositor Thread 竞争：Canvas 绘图、视频解码、或
will-change: transform过度使用，会抢占合成线程资源，导致主线程提交的帧被卡住——此时Main Thread看似空闲，但Paint就是不上屏
INP 异常时，先打开 Performance 面板的 Rendering 和 Layout 子轨道，别只盯着 JS Call Stack。那些看不见的样式重算和图层合成，往往比一段 100ms 的 for 循环更致命。
