拒绝“无法复现”：前端全链路日志排查实战手册

随着业务的快速迭代，前端应用早已不是简单的页面展示，而是承载了复杂逻辑的富客户端。作为前端工程师，我们最怕听到的一句话就是："线上有个 Bug，你快看一下。"

线上问题往往具有突发性（突然报错）、复杂性（链路长）和环境多样性（各种奇葩浏览器）的特点。如果没有一套系统化的排查思路，很容易陷入"无头苍蝇"式的乱撞，或者简单回复一句"本地无法复现"而不了了之。

本文基于团队多年的实战经验，梳理了一套前端线上问题排查 SOP（标准作业程序），涵盖从信息收集、链路分析到日志定位的全流程，希望能为大家提供一种系统化的解题思路。

收到问题反馈时，首要任务绝对不是立即去翻代码，而是收集足够的上下文信息。信息越全，定位越准。我们要求运营或客服反馈问题时，必须提供以下"三要素"：

很多"灵异"问题都源于环境差异：

拿到信息后，不要急着看日志，先在脑海中进行一次"二分法"快速诊断：

时间维度：该功能最近是否有上线？配置是否有变更？（排查新代码引入 Bug）。
范围维度：
- 普遍问题 ：所有人都不行 代码 Bug 或 后端服务挂了。
- 个性问题 ：只有他不行 环境、网络、缓存、权限问题。

A. 网络与安全策略（优先级 High）

B. 客户端兼容性

C. 权限与配置

当前端无法复现时，必须依靠全链路日志。一个标准的前端请求链路如下：

用户浏览器 CDN 、 WAF (防火墙)、网关/LB 、 BFF (Node中间件)、后端服务

我们需要熟练使用各个节点的日志工具：

工具：Sentry / 自研前端监控 SDK。
关注点：
- JS Error：直接定位代码堆栈（Stack Trace）。
- Resource Error：静态资源加载失败（如 CSS/JS 404）。
- Performance：页面加载耗时，判断是网络慢还是渲染慢。

工具：阿里云/AWS日志控制台。
典型现象 ：接口返回 405 或 403。
排查思路：
- 查看 WAF 日志中的 block_action。如果 real_client_ip 来自境外或高频访问，可能被误判为恶意攻击并自动封禁。
- 解决：联系安全团队将客户 IP 加入白名单。

工具：Kibana (ELK)。
关键技巧：这是区分"前端锅"还是"后端锅"的分界线。
- 查询 Client、 Node 的日志：看前端传参是否正确。
- 查询 Node 、 Backend Service 的日志：这是最关键的一步。
  - 如果 Node 发出的请求参数正确，且后端返回了错误码/Null、 后端问题。
  - 如果 Node 处理逻辑报错、 前端 BFF 问题。

高效的问题排查不仅仅是技术能力的体现，更是流程的胜利。

希望这份排查思路能帮助大家从"救火队员"转变为"系统医生"，让线上问题不再成为噩梦。