面试官最爱问的“线上事故”：白屏紧急救助方案

QLuckyStar
8 阅读5分钟

线上出现白屏或报错是前端最严重的生产事故之一。在2026年的技术环境下，排查这类问题需要一套从监控告警到本地复现，再到代码定位和修复的标准化流程（SOP）。

以下是详细的排查步骤和策略：

第一阶段：紧急止损与初步诊断（黄金5分钟）

1. 确认影响范围与回滚（首要动作）

  • 动作：  立即查看监控大盘（如 Sentry, Datadog, 自研监控）。

    • 是个别用户还是所有用户？
    • 是特定浏览器/设备/地区，还是全局？
    • 错误率是否瞬间飙升？

  • 决策：  如果错误率超过阈值（如 >5%）且影响核心业务，不要犹豫，立即执行版本回滚。先恢复服务，再排查问题。

2. 收集关键信息

  • 用户反馈：  截图、操作步骤、浏览器版本、设备型号、网络环境。
  • 监控日志：  获取具体的 Error Message、Stack Trace（堆栈追踪）、User ID、Session ID、URL、Referer。

第二阶段：深入定位问题根因

根据错误类型，分场景排查：

场景 A：JavaScript 运行时错误（最常见）

  • 现象：  页面部分功能失效，控制台报红，或完全白屏（React/Vue 根组件崩溃）。

  • 排查手段：

    1. 查看 Source Map：  线上代码通常是压缩混淆的（如 app.a1b2c3.js）。利用监控平台自动解析的 Source Map，将报错行号映射回源代码的具体位置。

    2. 分析堆栈：  确定是哪个函数、哪个组件抛出的异常。常见原因：

      • 访问了 undefined 或 null 的属性。
      • 数据类型不匹配（TS 编译通过但运行时数据异常）。
      • 第三方库版本冲突。

    3. 全局捕获检查：  确认 window.onerror 或 window.onunhandledrejection 是否捕获到了该错误。如果没有被捕获，可能是脚本加载失败或语法错误导致脚本未执行。

场景 B：资源加载失败（404/403）

  • 现象：  白屏，Network 面板中 JS/CSS 文件请求失败。

  • 排查手段：

    1. 检查 CDN 状态：  是否 CDN 节点故障？是否发布了新文件但 CDN 未刷新？
    2. 检查文件名哈希：  前端构建生成的文件名带 Hash（如 main.v1.js），如果 HTML 中引用的 Hash 与服务器实际文件不一致（例如部署顺序错误：先清除了旧文件，HTML 还没更新），会导致 404。
    3. 检查 CSP 策略：  是否因为 Content-Security-Policy 配置过严，拦截了脚本执行？

场景 C：接口数据异常（500/502/数据格式变更）

  • 现象：  页面骨架屏一直转圈，或渲染后数据为空导致崩溃。

  • 排查手段：

    1. 查看 Network 请求：  接口是否返回 5xx 错误？
    2. 检查数据结构：  后端是否在不通知的情况下修改了 API 返回结构（如字段改名、类型变化），导致前端解析代码（如 data.list.map）报错。
    3. 跨域问题：  是否出现了新的 CORS 错误？

场景 D：兼容性或特定环境问题

  • 现象：  只有 iOS 微信浏览器报错，或只有旧版 Chrome 白屏。

  • 排查手段：

    1. Polyfill 缺失：  是否使用了新的 ES 语法（如 Optional Chaining ?.）但未正确转译？
    2. CSS 兼容性：  是否使用了不支持的 CSS 特性导致布局崩坏？
    3. 内存泄漏：  在低配设备上是否因内存溢出导致进程崩溃？

第三阶段：本地复现与修复

1. 模拟生产环境

  • 工具：  使用 Chrome DevTools 的 Device Mode 模拟移动端；使用 Network Throttling 模拟弱网。
  • Mock 数据：  根据线上报错的 Response 数据，在本地 Mock 相同结构的异常数据，尝试复现 Bug。
  • Source Map 调试：  在本地构建时开启 Source Map，直接断点调试线上对应的代码逻辑。

2. 编写修复代码

  • 防御性编程：  增加可选链操作符 (?.)、空值合并运算符 (??)、try-catch 包裹风险代码。
  • 降级策略：  如果某个非核心组件报错，使用 React Error Boundaries 或 Vue errorCaptured 捕获错误，展示“组件加载失败”的占位图，而不是让整个页面白屏。

3. 验证与回归

  • 在测试环境验证修复方案。
  • 确保修复不会引入新的回归问题。

第四阶段：复盘与预防（长期建设）

问题解决后，必须进行复盘，避免同类问题再次发生：

  1. 完善监控体系：

    • 前端监控 SDK：  确保覆盖 JS 错误、资源加载错误、接口异常、白屏检测（通过定时检测 DOM 节点或首屏时间）。
    • 用户行为回溯：  集成类似 "Replay" 的功能（如 RRWeb），记录用户报错前的操作轨迹，便于复现。

  2. 优化 CI/CD 流程：

    • 自动化测试：  增加单元测试（Jest/Vitest）和 E2E 测试（Playwright/Cypress），覆盖核心链路。
    • 灰度发布：  严禁全量发布。先放量 1% -> 5% -> 20% -> 100%，观察监控指标无误后再全推。
    • 构建检查：  在构建阶段增加 TypeScript 类型检查、ESLint 校验、Bundle 大小预警。

  3. 代码规范与审查：

    • 强制要求对异步操作、外部数据输入进行判空处理。
    • Code Review 时重点关注边界条件和异常处理逻辑。

💡 面试回答话术示例（STAR 法则）

“在我之前的项目中，有一次上线后收到反馈说部分用户白屏。

（Situation）  当时监控显示 JS 错误率瞬间飙升到 15%，主要集中在 iOS 微信环境。
（Task）  我的首要任务是快速恢复服务并定位根因。
（Action）

  1. 我首先确认了影响范围，发现是新版本的某个 Polyfill 在旧内核 WebView 中未生效。
  2. 由于影响较大，我立即协同运维执行了版本回滚，5分钟内恢复了服务。
  3. 随后，我通过 Sentry 的 Source Map 还原了堆栈，发现是使用了 Array.prototype.at() 方法，而构建配置中对该环境的 Babel 转译遗漏了。
  4. 我在本地模拟了该环境复现了问题，修复了 Babel 配置，并增加了针对该方法的单元测试。

（Result）  修复重新灰度发布后正常。事后，我推动了团队在 CI 流程中加入‘目标浏览器兼容性自动检测’环节，并完善了白屏监控报警机制，此后类似事故再未发生。”

这种回答既展示了应急处理能力，又体现了技术深度和工程化思维。

avatar
文章
阅读
粉丝