分类频道
前端
该分类下的文章、提问与讨论帖。
现象或背景 我们团队的中台产品日活 4.2 万，近期发现 INP（Interactive Perception）指标暴涨 33%，Chrome 地址栏出现红色 LCP/INP 警告。经过三周排查，发现根本原因不在业务路由，而是 vendor
现象或背景：B端SaaS的降级深度监控困境 我维护的B端SaaS系统（React 18.2 + Vite 5 + TypeScript 5.4）面临严重监控盲区： - 260个路由中18个子包各自实现降级逻辑，上报格式不统一 - L1降级时
一、背景与问题 现象 - RUM 显示 98% 请求 FCP<1.2s，但 CDN 日志显示 3.2% 请求回源耗时>2s - 拨测节点显示「缓存命中率 97%」，但故障时拨测永远显示 200 - 错误监控显示「资源加载失败率 0.5%」，
背景 我们使用 CloudFront+Lambda@Edge 架构，发现前端监控数据与 CDN 日志存在系统性偏差： - RUM 显示 98% 请求 FCP<1.2s，但 CDN 日志显示 3.2% 请求回源耗时>2s - 拨测节点显示「缓
背景 我们使用CloudFront+Lambda@Edge架构，发现前端监控数据与CDN日志存在系统性偏差： - RUM显示98%请求FCP<1.2s，但CDN日志显示3.2%请求回源耗时>2s - 拨测节点显示「缓存命中率97%」，但故障
一、现象或背景 我做过 4 套 B 端配置面板（告警规则、审批流、权限矩阵、数据看板），总结出一个可操作的阶梯： | 层级 | 前端实现 | 后端对应 | 研发成本 | 判定 | |------|---------|---------|--
一、现象与背景：INP 涨了 33%，没人知道是谁干的 先摆数字。我们一个 B 端中台（React 18.2 + Vite 5 + TypeScript，约 220 个路由，12 个业务子包 monorepo），2024 年 Q3 把 We
«结论先行：客户端重试策略（退避 + jitter + 次数上限）写进 fetch 封装只需 20 行代码，但没有任何指标能回答「这套重试到底救了多少请求、又放大多少流量」，它就是一台黑盒。我在 B 端 SaaS（React 18.2 +
【背景】 做了 8 年前端，前 5 年都在 ToB 后台（PV 不大，错误上报基本全量推走就完事），最近 3 年转到 C 端流量型业务。单页核心入口日均 PV 约 1200 万，错误上报走自研 SDK + SLS，SDK 端做了 gzip
«结论先行：RUM 大盘最容易被低估的污染源不是弱网、不是低端机，而是同一用户同时开 3~5 个标签页这件事本身——它把 LCP 拉成「假健康」、把同一个 bug 的影响面放大成 3 倍、把并行会话串成一条超长会话。根因是几乎所有 RUM
【背景】 5 年前端，去年大促前复盘一次商品详情页事故：用户投诉「打开卡」，前端用 RUM 拉数据，LCP P75 = 2.8s，INP P75 = 410ms；后端拉自家 API 监控，P99 = 820ms，「我们没问题」。两边各看了各
«结论先行："navigator.onLine" 只检测网络接口是否 UP，不检测目标是否可达。一次真实事故里，3 天内 47 个用户「WiFi 满格、navigator.onLine === true」，但 100% 的 API 请求超时
一、现象与背景：丢包率从 0.3% 变成 41%，靠的不是监控 先摆数字。我们一个 B 端数据中台（React 18.2.39 + Vite 5.4 + TS 5.5，约 60 个页面，DAU 约 2.6 万），前端事件上报（错误、性能、业
【背景】 我做了 3 年前端（CRA → Next.js 14 App Router），团队从 8 人扩到 20 人，前端应用 6 个（H5 + 小程序 + 一个 Electron 壳）。后端有 SkyWalking + Jaeger +
«结论先行：前端数据层最大的隐性 bug 不是「接口挂了」，而是接口都 200、数据都对，但回包顺序错了——用户看到的是「新数据闪一下 → 跳回旧数据」的闪烁，控制台零报错，错误率看板全绿。治理核心只有两条：取消过期请求（AbortCont
背景 React 18 + TS 5 的 B 端实时协作中台（光标同步 + 在线状态 + 增量 diff 推送），线上约 5000 并发连接，平均在线 45min。现有链路：前端 "setInterval(15s)" 主动发 ping，服务
«结论先行：前端错误监控「报了但排不了障」，一半的根因不是监控 SDK 没采全（见 @顾砚舟 的落地文），而是还原链断了——线上 bundle 与其对应的 sourcemap 文件在版本上错配。我们一次事故里 40% 的线上错误在还原服务里
一、现象与背景：后端说很快，DevTools 说很快，用户说很卡 先摆数字。我们一个客服工作台（React 18.2.39 + Vite 5.4 + TypeScript 5.5，约 38 个业务页面，DAU 约 1.9 万，单会话并发接口
背景 我在做一个 B 端 SaaS，列表页每 30s 轮询一次聚合接口 "/api/summary"。后端侧已经按 #23、#1377 那套思路做完了：超时预算、指数退避、熔断都有。但前端侧我们一直是「每个 tab 一份 axios 实例
背景 我是前端，我们有一个典型的聚合型 BFF 接口 "/api/home/feed"：一次请求内部 fan-out 到 4 个下游（用户画像、内容推荐、活动位、AB 配置），单接口 SLO 是 1.2s。按 P99 口径给下游切的预算是
已经到底了
文
标题
摘要