React 项目实践

如何建设 React 项目的错误监控和性能观测？

线上观测要让错误可定位、性能可分组、用户可恢复，并且不泄露敏感数据。

适合阶段：资深前端 / 技术负责人核心能力：错误治理 · RUM · 可观测性

面试官想考什么

• 错误边界能捕获哪些错误？ 考察 React 运行时边界。
• 一条前端错误如何关联到后端请求？ 考察 trace 设计。
• 性能指标如何分组和采样？ 考察数据分析能力。
• 如何处理隐私和告警噪声？ 考察生产治理。

一句话回答

React 可观测性要把错误边界、请求 trace、版本、路由、用户环境和 Web Vitals 串起来，并提供脱敏、采样、告警和恢复路径。

面试回答详解

1. 错误分类

• 渲染错误：由错误边界捕获并展示局部降级。
• 事件和异步错误：需要在事件处理、请求层和全局 unhandled rejection 处上报。
• 资源错误：脚本、图片、字体和 chunk 加载失败要单独识别。
• 服务端错误：保留 request id、release 和路由上下文。

2. 观测字段

release + route + user/tenant hash + device + request id
+ error boundary + action + downstream status

用户和租户信息必须最小化、脱敏或哈希化；不要上报 token、完整表单和敏感业务数据。

3. 性能观测

记录 LCP、INP、CLS、TTFB、长任务、React render/commit、资源加载和业务成功率。实验室数据用于复现，RUM 用于真实设备、地区和网络分组。

4. 闭环

告警要能关联版本和变更，错误页面给用户 retry、刷新或返回路径；高风险 release 支持 feature flag、kill switch 和回滚。每次修复要补回归测试和监控查询。

可直接背诵的 30 秒回答

我会把渲染、事件、异步、资源和服务端错误分类采集，统一带上 release、路由、环境、请求 trace 和必要的用户上下文，并做脱敏和采样。性能侧关注 LCP、INP、CLS、TTFB、长任务和业务成功率，结合实验室与 RUM 定位。告警必须能落到版本和恢复动作，而不是只发一条堆栈。

扩展知识

最小排障链

用户反馈 -> 错误事件 -> release/route -> request trace
-> 下游日志 -> 复现 -> 修复 -> 回归与告警验证

面试官追问链

追问一：错误边界能捕获 Promise rejection 吗？

• 考察点：是否理解错误边界范围。
• 回答方向：通常不能自动捕获事件处理和异步回调中的错误，应在请求层、事件层或全局 rejection 处理器上报并做用户恢复。

追问二：为什么用户说慢但平均耗时正常？

• 考察点：是否会看分布和人群。
• 回答方向：看 P95、低端设备、移动网络、地区、登录态、第三方脚本和特定路由，而不是只看平均值。

追问三：如何避免监控本身影响性能？

• 考察点：观测成本意识。
• 回答方向：异步上报、采样、批量发送、资源延迟加载、字段裁剪和失败静默；关键错误优先级高于详细性能样本。

推荐阅读

• React Error Boundaries
• React Performance Tracks
• web.dev Core Web Vitals
• React 项目实践