用户投诉"页面卡"，前端和后端各自拿什么数据自证清白？分界线到底画在哪

背景

我做了 3 年前端，最消耗精力的往往不是写功能，而是这类现场：运营转来一句"用户反馈下单页很卡"，前端第一反应是"接口慢"，后端第一反应是"你们前端渲染慢"。我复盘过几次，最后发现真正的根因五花八门——有的是弱网下图片阻塞，有的是后端 P99 抖动，还有最尴尬的一种：两边都没问题，是用户手机本身性能差。但在拿到结论之前，谁先开口谁先被动，这是很多团队的真实痛点。

社区里 #431 聊过稳定性投入的最低水位，#513 讨论过性能预算，但我发现大家很少正面聊「责任分界线的观测手段」——即：当"卡"这个模糊投诉进来时，前端、后端、网关各自应该拿出什么样的数据，才能 5 分钟内把锅分清楚，而不是吵 3 天。

常见分歧（我观察到的三种做法）

1. 前端全量自证派：RUM 采集 FCP/LCP/INP + 每个请求的耗时分解（DNS/TCP/TLS/TTFB/download），用 TTFB 高就甩给后端。问题：用户侧网络差时 TTFB 天然高，会把弱网用户全算成"后端慢"。
2. 网关仲裁派：以网关日志为准，请求进出网关的时间戳是"最接近中立"的证据。问题：网关看不到的部分（用户到网关之间的链路、后端到下游的耗时）恰恰经常是根因。
3. TraceId 全链路派：前端把 traceId 注入每个请求，后端用 OpenTelemetry 串起来，一张瀑布图定责。问题：落地成本高，而且用户的浏览器到网关这一段 trace 是断的，瀑布图里照样有一块空白。

我的倾向与理由

我倾向「分段计时 + 基线对比」的折中方案，落地成本可控：

• 前端侧：performance.timing 拆出 TTFB 和 download，但要按网络类型（navigator.connection.effectiveType）和地区分桶，弱网用户单独看基线，别和 Wi-Fi 用户混在一起比；
• 网关侧：记录同一 traceId 下的 upstream_response_time，这是后端真实耗时的锚点；
• 关键动作：每周跑一次"同接口、同地区、同网络档位"的前端 TTFB 分布 vs 网关 upstream 时间分布的对比，两者差值稳定在某个水位内就证明链路没问题，差值突然拉大就是某一段出事了。

这样责任分界线不是画在某一行代码上，而是画在「哪一段的耗时分布偏离了自己的历史基线」上——谁偏离谁解释，比互相甩锅客观得多。

想听大家聊聊

1. 你们团队"用户说卡"这类投诉，实际是怎么定责的？有没有一个公认的仲裁点（网关日志？RUM 平台？某个值班群？）
2. 前端采 TTFB 时，弱网用户的数据你们会剔除还是单独建基线？
3. traceId 贯通到浏览器端，你们是真做了还是只做到网关为止？成本大概多少人周？
4. 如果让你只加一个观测点来减少甩锅，你会选哪个？

欢迎带着你的团队规模和踩坑细节来聊，泛泛而谈的"要做全链路"恕不接招 :)