线上 INP 劣化 30% 却难以归因到具体代码改动，如何建立可复现的前端性能归因链路？

【背景】 我们是一个 React 18 + Webpack 5 的中后台 SPA，约 200 个路由、60+ 个三方 SDK（埋点、IM、风控、客服等）。今年开始把 Web Vitals 纳入稳定性大盘，INP 目标 < 200ms。

【现象】 近两个月 INP P75 从 158ms 涨到 205ms，劣化约 30%。但每次发布都有几十个改动，无法判断是哪个 PR / 哪个 SDK 版本引入的。RUM 数据里只能看到「Long Task 时长 P75 从 60ms 涨到 110ms」，但 task 内部被拆成多个 slice，slice 命名都是匿名函数，对不上源码。

【已尝试的排查】

1. PerformanceObserver 打 longtask + eventtiming，但 slice 只有 duration，没有 attribution；
2. 给 React 渲染路径包了 Profiler，线上只采 1% 用户，样本太少且 Profiler 本身的开销让 INP 再涨 15%，数据失真；
3. 试过按 bundle 维度上报（webpack splitChunks 后给每个 chunk 打 hash），但 INP 劣化往往发生在「主线程总耗时」上，跨 chunk 的 SDK 调用链没法按 chunk 切开；
4. 灰度发布时 A/B 对照，但流量太小、用户机型分布不均，置信度不够。

【期望得到的答案形态】

1. 一套线上可落地的 INP / Long Task 归因方案：在什么时机采、采哪些字段、如何把 task 归因到「某个 SDK / 某个 React 组件树 / 某次 setState」，最好有可复现的埋点代码片段；
2. 如何在不显著影响性能的前提下做线上 Profiling（比如采样策略、Profiler 开销的量化方法）；
3. 发布前 / 发布后的性能回归卡点怎么做（CI 里跑 Lighthouse 是否够？线上灰度 A/B 的样本量与置信度怎么算）；
4. 三方 SDK 的 INP 贡献度怎么隔离测量（比如用 PerformanceObserver 的 duration 减去「无 SDK 版本」的 baseline？还是用 Worker offload 对比？）。

我比较关注工程可复现性，最好能给出埋点代码、采集频率、上报字段设计，而不是只讲原理。