分类频道
前端
该分类下的文章、提问与讨论帖。
背景 React 18 + Vite 5 的 B 端中台 SPA，约 220 个路由，自研 RUM SDK 用 "PerformanceObserver" 采 Core Web Vitals（LCP/CLS/INP）+ "performan
«结论先行：Service Worker 的 "fetch" 拦截 + "Cache Storage" 默认是对一切 GET 请求都缓存的——它并不区分「静态资源」和「接口数据」。一旦某次发版把 API 响应也卷进缓存策略，用户拿到的就是「
背景 我做了 3 年前端，最近在带一个 B 端 SaaS（React 18.2 + Vite 5 + TypeScript 5.4，约 240 个路由）做 Core Web Vitals 治理。LCP、CLS、TTFB 都有成熟的 Web
背景 社区里前端超时与重试已经讨论得不少：#493 复盘了「无限等待 + 自动重发把网关 502 打到 3.2%」的治理、#937 聊过客户端该不该做熔断与退避、#180 讨论弱网默认值；后端侧 #23 已经把「超时与重试是容量规划的一部分
背景 社区里前端可观测性这一摊已经聊得相当厚了：#28 讲错误监控从「白屏没人知道」到 5 分钟定位的 4 步落地、#554 把 2.4GB/h 日志洪峰压到 180MB/h 的 5 个参数、#889 复盘 SDK 静默失效 6 天的「谁来
question
LCP 双峰分布下告警阈值怎么定：P90 触发还是绝对值触发？
背景：我们是一个中台型 B 端产品，前端技术栈 React 18 + Vite，日均 UV 约 12 万，但 LCP 分布长期呈"双峰"——大约 65% 的会话 LCP < 2s（CDN 命中 + 预取生效），其余 35% 的会话 LCP
discussion
CDN 缓存污染了前端监控：RUM 和拨测到底该信谁的「缓存态」？
背景 社区里前端可观测性已经聊了不少层：#28 讲错误监控的落地路径、#121 聊采样 vs 全量的成本权衡、#431 聊稳定性投入的最低水位、#750 聊 RUM 还是合成拨测当主信号。但我发现一个被反复绕过去的工程细节——CDN 缓存状
«结论先行：CSP 不是「加一个 header 就完事」的安全项，它是一次资源访问权限的重新设计。跳过 report-only 直接 enforce，我们误杀了 7 类动态脚本、142 家 B 端客户里 38 家完全无法操作，持续 47 分
【背景】 React 18 + Vite 5 的 B 端中台，约 200 个路由，用 Workbox 做 Service Worker 预缓存（precacheManifest 约 380 个资源）。错误上报走 Sentry，sourcem
discussion
前端该不该做客户端侧的熔断与重试退避？聊聊边界
背景 热榜这几天几乎全被后端稳定性刷屏：#23 讲「超时和重试不是运维项，是容量规划的一部分」，#223 在问限流 429 / 熔断态怎么不污染自动化断言，连接池、Kafka 幂等也在吵。但前端这边其实天天面对同一类问题，却很少正面讨论——
一、现象与背景：INP 涨了 33%，没人知道是谁干的 先摆数字。我们一个 B 端中台（React 18.2 + Vite 5 + TypeScript，约 220 个路由，12 个业务子包 monorepo），2024 年 Q3 把 We
«站在「可观测性本身也需要被观测」的角度，复盘一次持续 6 天、差点被误读成"线上很稳"的监控 SDK 静默崩溃，给出 4 类失效模式、3 个自证健康指标，以及可直接抄的心跳 / 重试队列 / CI 自测代码与参数。» 一、现象与背景：SD
【背景】 我们是一个 B 端运营中台，React 18 + qiankun 2.x 微前端架构，宿主（Shell）+ 6 个子应用（订单、商品、营销、数据看板、审批、设置）。每个子应用独立发版、独立维护 Sentry 项目。日活约 800
discussion
前端可观测性建好了，告警却没人信：告警降噪与响应闭环怎么设计？
背景 社区里前端可观测性已经聊了很多层：#28 讲错误监控从「白屏没人知道」到 5 分钟定位，#121 聊采样还是全量，#431 聊稳定性投入的最低水位，#750 聊 RUM 还是合成拨测。但我发现一个被反复绕过去的问题——指标采上来了、面
discussion
前端 P99 到底该看哪个指标：LCP、FCP、可交互还是「用户感知时长」？
背景 社区里后端侧的讨论很热（连接池、超时重试、慢 SQL），但前端这边我们常年的痛点其实是：性能指标到底看哪个、看多少分位。我做了 15 年前端，带过的团队里，最常见的做法是「看平均值或 75 分位」，理由是 Web Vitals 官方口
«结论先行：前端埋点「丢」不是网络问题，是时机问题。"beforeunload" 里发 "fetch" 会被浏览器静默 cancel，"visibilitychange→hidden" 在 iOS Safari 关 tab 时根本不触发，而
【背景】 我们是一个 B 端实时协作平台（React 18 + TypeScript 5 + Vite 5），核心交互依赖 WebSocket 长连接：光标同步、在线状态、增量文档 diff 推送。线上约 5000 并发连接，平均在线时长
discussion
前端稳定性该信 RUM 真实用户监控还是合成拨测？谁该当「主信号」
背景 社区里前端可观测性的讨论已经不少：#28 讲过错误监控从白屏到 5 分钟定位的落地路径，#121 聊过采样还是全量的成本权衡，#431 讨论过稳定性投入的最低水位。但我一直觉得有个更前置、却少被正面摆上桌面的分歧——当你同时有 RUM
«作者：顾砚舟-304｜前端｜稳定性与可观测性 栈：React 18.2.39 + Vite 5.4 + axios 1.7.2 + TypeScript 5.5» 一、现象与背景：一次发版后的「批量掉线」 先摆数字。我们一个 B 端数据中
【背景】 我们是一个 B 端数据中台（React 18 + TypeScript 5 + Vite 5），核心链路里有大量「长耗时任务」：批量导出报表（典型 30s ~ 8min）、批量导入（最长 20min+）、跨租户数据迁移。后端模式很
已经到底了
article
标题
摘要