线上 INP（P75 长期 320ms+）长任务怎么稳定归因到「具体 React 组件 / 第三方脚本」：PerformanceObserver(longtask) + React Profiler + async stack 三套数据怎么在线上报闭环？

背景

我做了 3 年前端，最近在带一个 B 端 SaaS（React 18.2 + Vite 5 + TypeScript 5.4，约 240 个路由）做 Core Web Vitals 治理。LCP、CLS、TTFB 都有成熟的 Web Vitals 库 + RUM 上报方案，但 INP（Interaction to Next Paint）这块我们卡住了：内部大盘 P75 长期 320ms–480ms，Chrome UX Report 里 30% 用户超标，但每次打开 DevTools 只能看到「主线程被阻塞 2xx ms」，具体是哪个组件 render、哪个 setState、还是某个第三方脚本（埋点 / IM SDK / 客服挂件）导致的，全靠用户反馈 + 本地复现，无法在线归因。

社区里前端可观测性已经讨论得不少：#28 把「错误对不上号」的治理讲透了、#162 给了内存泄漏的 Heap Snapshot 三步证据链、#630 聊过前后端卡顿定责的分界线怎么画。但我观察到的现状是——大家把 INP 当作一个 Lighthouse 分数去优化，而不是当作一个可归因的线上事件去处理。

现象与卡点

1. PerformanceObserver({type: 'longtask'}) 在线上报只能拿到 duration 和 attribution.name（第三方脚本能拿到，React 内部拿不到具体组件）；
2. React 18 的 Profiler（onRender/onCommit）我们只在线上「白屏排查」时临时打开过，常态化打开有 20%+ 的 render 开销，且 Profiler 回调里没有「这次 render 是否导致了 INP 长任务」的关联信息；
3. async stacktrace（Error.prepareStackTrace 或 --async-stack-traces）在生产 Chrome 里只能拿到 2–3 层 async 帧，跨 requestAnimationFrame / setTimeout 就断了；
4. 我们的埋点 SDK 是第三方注入的 <script>，longtask.attribution 能拿到它的 name，但拿不到「它做了什么」，无法进一步区分是它的 sendBeacon 还是它的 setState 触发了 React re-render；
5. 最尴尬的一种：INP 超标但 longtask 事件一条都没有——主线程被切成 80ms × 4 段，每段都没过 50ms 阈值，但用户感知就是「点没反应」。

已尝试的排查与结果

• 方案 A：PerformanceObserver(longtask) + 全局 window.__LONGTASK_STACK__（在 rAF 入口打点）上报，拿到的是「哪个第三方脚本」但拿不到「哪个 React 组件」；
• 方案 B：线上全量开 React.Profiler，onRender 回调里把 commitMs > 50 的渲染打点上报，结果发现 Profiler 本身把 P75 INP 从 320ms 推到 410ms（自证了 Profiler 开销），且 commitMs 和 INP 的 duration 对不上（INP 算的是「输入到下一帧」，commitMs 是「reconcile + commit」，中间还有 paint）；
• 方案 C：PerformanceObserver({type: 'event'}) + processingStart/processingEnd，能拿到 duration，但 attribution 里只有 target 的 tagName，没有 React fiber 信息；
• 方案 D：本地用 DevTools Performance 面板手动录 + 二分注释，能定位到 2 个具体组件（一个 200 行的表格 render 里做了 JSON.parse + map，一个 antd Tree 的 onSelect 里同步 setData），但线上 30% 超标的用户里，本地复现只覆盖了 12%，剩下 18% 归因不到。

期望得到的答案形态

1. 采样策略：INP 的归因数据不能全量上报（体积 + 端侧开销），你们线上是怎么定「哪些用户 / 哪些会话上报归因明细」的？是按 INP > 阈值才触发，还是按 session 采样？采样率怎么定？
2. 组件级归因：在线上（不是本地 DevTools）把 INP 长任务归因到「具体 React 组件」，你们有没有比「全量开 Profiler」更轻的方案？比如 fiber 树快照 + 增量 diff？或者用 React.debugRender 之类的钩子？
3. 第三方脚本归因：longtask.attribution.name 拿到脚本名后，怎么进一步区分「是它自己的代码阻塞」还是「它触发了 React re-render」？有没有在线上注入 MutationObserver 或 hook ReactDOM.render 做归因的实践？
4. sub-50ms 长任务：longtask 事件抓不到的「多段 80ms 卡顿」，你们线上怎么观测？是不是只能靠 eventtiming + 用户上报？
5. INP 与 commitMs 的换算：React.Profiler 的 commitMs 和 INP 的 duration 差值（paint 耗时）你们是怎么补全的？requestAnimationFrame 回调里打点？

引用

• #28 《前端线上错误监控：从「白屏没人知道」到 5 分钟定位的 4 步落地》——错误归因的四步法我借鉴到了 INP 治理，但「对不上号」的最后一公里在 INP 上还没解。
• #162 《前端内存泄漏排查：用 Heap Snapshot 把「越用越卡」从猜测变成 3 步证据链》——「该死的对象还活着」的证据链思路，我套到了 INP 上：长任务 = 该让出的帧还没让出。
• #630 《用户投诉"页面卡"，前端和后端各自拿什么数据自证清白？分界线到底画在哪》——前后端定责的分界线，在 INP 上变成了「主线程谁在占用」，这条线我还没画清楚。