解决前端线上问题，核心原则是先止血、再定位、后复盘。线上故障的第一优先级永远是控制影响面，而不是追求完美修复。下面按“发现 → 定级 → 止血 → 定位 → 复盘”五个环节，给出一套可落地的标准化流程。
🔍 第一步：发现——让问题自己“报上来”
不要等用户反馈，要在用户大规模感知之前自己发现。
1. 分层监控体系
- 错误监控（Sentry）：捕获 JS 异常、资源加载失败、Promise 未处理拒绝。配置自定义告警规则，例如“5 分钟内错误率 > 5%”或“特定 API 错误频次超阈值”，自动触发飞书/钉钉告警。上线前务必确认
release版本号已注入、Source Map 已上传，否则线上堆栈无法定位到源码。 - 性能监控（RUM）：关注 LCP、INP、CLS 的 P75 分位，以及接口成功率、P95 耗时。性能劣化往往先于功能故障出现。
- 业务监控：在关键节点（下单成功回调、支付完成回调）主动上报，业务成功率下降即使没有 JS 报错也是严重信号。
- 白屏监控：在 WebView 或页面入口加入
onPageFinished+ 超时检测，主动捕获白屏而不是等投诉。
2. 告警降噪
在 Sentry 的 beforeSend 中过滤浏览器扩展错误、ResizeObserver loop 等常见噪音，避免告警疲劳。告警信息必须包含版本号、路由、用户 ID、错误堆栈、Request ID，否则等于没有告警。
🚨 第二步：定级——决定投入多少资源
不是所有线上问题都值得全员停下。用四级分类快速定级：
| 级别 | 定义 | 响应目标 |
|---|---|---|
| P0 致命 | 核心业务中断（白屏、支付失败、无法登录） | 30 分钟内恢复，立即停下手头一切工作 |
| P1 严重 | 主要功能受损但系统仍可用 | 2 小时内制定方案 |
| P2 一般 | 非核心功能问题，影响部分用户 | 24 小时内修复 |
| P3 轻微 | 界面瑕疵或优化建议 | 纳入常规迭代 |
定级后立即在统一渠道拉群，群名标准化（如 〖P0〗支付系统_1018_001），第一条消息必须包含：现象描述、影响范围、已确认信息、所需协助。
🩹 第三步：止血——控制影响优先于根因
这是线上问题处理和日常 Debug 最大的区别。如果 30 分钟内无法定位根因，优先止血，不要继续排查。
止血手段按速度排序：
- 功能开关（Feature Flag） ：如果问题功能被开关包裹，在配置中心一键关闭，秒级生效，无需发版，是最快的止血手段。
- 回滚：如果问题由本次发布引入，直接回滚到上一个稳定版本。上线前就应明确回滚触发标准（如灰度期间错误率 > 1% 或出现阻断性 Bug），并熟悉平台的即时回滚操作。
- 降级：关闭非核心功能、切换到备用接口、展示缓存数据或静态兜底 UI。例如组件报错时用 ErrorBoundary 展示降级 UI 而非整页白屏。
- 灰度/切流：如果问题集中在特定区域或特定用户群，先将流量切走或暂停灰度放量。
止血期间，不要修改出问题的环境。先保存现场（代码版本、配置、错误日志、请求 ID），再操作回滚或降级，否则复盘时无法复现。
🧭 第四步：定位——结构化排查，按依赖方向逐层收窄
止血之后，再从容定位根因。不要东一榔头西一棒子，按依赖方向从上游到下游排查。
通用排查路径（以白屏为例）：
断点一：资源请求层
打开 Network 面板，按顺序确认：文档请求是否 200、入口 JS 是否 200、路由懒加载的 chunk 是否 404。常见原因：publicPath 配置错误、CDN 回源失败、history 模式子路径未配 fallback。
断点二：JS 执行层
如果资源都加载了但页面没动，检查控制台。常见原因：目标浏览器不支持的语法（polyfill 缺失）、异步回调中的静默失败、DOMContentLoaded 之前访问了未就绪的全局变量。
断点三：路由与渲染层
如果 JS 执行了但页面空白，检查路由守卫是否死循环、懒加载 chunk 是否为空、组件 setup/render 是否抛错导致挂载中断。
移动端/WebView 专项：
- JSBridge 失效：检查 H5 调用的接口名与 Native 注册名大小写是否一致（iOS 区分大小写，静默失败）。
- WebView 白屏：除了上述三层，还需确认 WebView 是否开启了 DOM Storage 权限、JSBridge 是否在页面脚本执行前已注入。
性能类问题（卡顿、内存泄漏）：
- Long Task：用 Performance 面板找 > 50ms 的红色长条，定位主线程阻塞点。
- 内存泄漏：用 Memory 面板做堆快照对比（操作前 vs 操作后 vs 重复操作后），关注
Detached DOM和 Retainers，找出谁在持有已卸载的节点。
判断前后端归属的快速方法： 把请求复制到 Apifox/curl 单独调用。单独调也错 → 后端；单独调正常但页面错 → 前端。用 Request ID 和后端高效沟通，不要只说“接口有问题”。
📝 第五步：复盘——把“这次”变成“下次不再”
48 小时内完成复盘，聚焦五个问题：为什么会发生？为什么没提前发现？处理过程哪里可以优化？如何避免类似问题？哪些经验可以沉淀？
用“切口式复盘”代替流水账： 不要从需求评审一路捋到上线，先找最反常的那个点作为切口。比如“测试环境正常、线上必现”，就盯着这个差异挖，挖到根就停，不东拉西扯。
复盘必须产出可执行的小事： 拒绝“加强测试流程”“提升工程师素养”这类正确的废话。例子：如果根因是配置参数漏校验，就直接写一个上线前自动比对配置与代码字段的小工具，不对就卡住发版。每个改进项要有负责人和完成时间，作为独立任务跟踪。
💎 总结
线上问题处理的核心不是“技术有多强”，而是流程有多稳。
| 阶段 | 核心动作 | 关键原则 |
|---|---|---|
| 发现 | Sentry + RUM + 业务监控 + 白屏监控 | 在用户投诉前自己发现 |
| 定级 | P0-P3 四级分类 | 按影响面分配资源，不搞平均主义 |
| 止血 | 开关 → 回滚 → 降级 → 切流 | 30 分钟定不了根因就止血，保存现场 |
| 定位 | 资源 → JS → 渲染，逐层收窄 | 按依赖方向排查，不跳步 |
| 复盘 | 切口式挖根因，落一件可执行的小事 | 对事不对人，改进项必须可验证 |
把这套流程固化到团队里，让每一次线上问题都变成一次可响应、可止血、可追溯、可改进的标准操作，稳定性才能从“靠运气”变成“靠体系”。
