
在 Java 后端面试中经常会遇到一些“线上问题排查类”的场景题。比如 一个页面之前显示正常但是刷新之后突然出现不断旋转的加载图标一直无法加载完成。你会怎 么排查这类题目考察的不只是某个具体知识点而是候选人是否具备完整的问题定位思路。回答时不要一上来就猜“是不是后端接口挂了”而应该按照链路逐层排查。———## 一、先明确问题范围页面一直转圈本质上说明页面处于 loading 状态没有结束。常见原因大致可以分为三类1. 前端代码报错导致页面渲染中断2. 接口请求没有正常返回页面一直等待数据3. 接口返回了但返回数据异常前端没有正确关闭 loading所以排查的第一步不是直接看后端日志而是先判断问题发生在哪一层。———## 二、先看浏览器开发者工具刷新页面后首先打开浏览器开发者工具也就是常说的 F12。重点看两个地方### 1. Console 控制台查看是否有 JavaScript 报错比如- 变量为空- 字段不存在- 数组或对象解析异常- 前端组件渲染失败- 路由跳转异常如果 Console 中有明显报错说明问题很可能在前端。比如接口返回的数据结构变化了前端仍然按照旧字段取值就可能导致页面渲染失败loading 状态无法关闭。### 2. Network 网络请求Network 是排查这类问题的重点。刷新页面后需要观察- 接口有没有发出去- 接口状态码是多少- 接口是否一直处于 pending- 接口耗时是否异常- 响应内容是否符合预期不同情况对应不同排查方向。———## 三、根据接口状态判断问题方向### 1. 接口一直 pending如果 Network 里某个接口一直处于 pending 状态说明请求没有正常返回。这时可能是- 后端接口执行时间过长- 数据库查询慢- Redis 调用卡住- 第三方接口没有响应- 服务线程池被打满- 数据库连接池耗尽- 网关或 Nginx 转发异常这种情况下后端需要根据请求时间、接口路径、请求参数、traceId 等信息去查日志。重点看接口是否进入了后端服务以及具体卡在哪一步。———### 2. 接口返回 500如果接口返回 500说明后端服务内部出现异常。这时应该查看后端日志中的异常堆栈例如- 空指针异常- 参数解析异常- SQL 执行异常- 数据库字段不兼容- 业务代码抛出异常- 远程服务调用失败排查时可以先定位到 Controller 是否接收到请求再看 Service 和 Mapper 层的执行情况。———### 3. 接口返回 401 或 403如果刷新页面后接口返回 401 或 403就要考虑登录态和权限问题。常见原因包括- token 过期- cookie 丢失- session 失效- 用户权限被修改- 刷新后重新获取用户信息失败- 前端没有正确处理未登录状态这种情况在后台管理系统中比较常见。有些系统在 token 过期后前端没有跳转登录页而是一直停留在 loading 状态看起来就像页面卡住了一样。———### 4. 接口返回 200但页面仍然 loading如果接口状态码是 200响应也返回了但页面还是一直转圈这时问题可能不在后端接口本身。需要继续看- 返回数据结构是否符合前端预期- 某些字段是否为空- 是否存在异常数据- 前端是否在异常分支中忘记关闭 loading- Promise、回调或异步逻辑是否没有执行 finally- 页面是否等待多个接口其中某个接口失败但没有处理例如页面需要同时请求用户信息、菜单权限和列表数据。如果其中一个接口返回的数据结构异常前端可能就无法进入正常渲染逻辑。———## 四、再查后端日志如果通过 Network 判断是接口问题就需要进入后端排查。排查后端时可以按照下面的链路看1. 请求有没有进入网关或 Nginx2. 请求有没有转发到后端服务3. Controller 有没有接收到请求4. Service 层业务逻辑是否正常5. 数据库、Redis、MQ、第三方接口是否正常6. 接口是否在某一步出现超时或异常对于 Java 后端来说可以重点关注- 应用日志- 异常堆栈- 慢 SQL- 数据库连接池状态- Redis 连接情况- 线程池状态- JVM GC 情况- 服务调用链路追踪如果系统接入了 SkyWalking、Zipkin、Pinpoint、CAT 这类链路追踪工具可以直接根据 traceId查看整个请求链路的耗时分布。———## 五、对比正常和异常情况因为题目中提到“之前显示正常刷新时突然出现问题”所以还需要做对比分析。可以对比- 正常请求和异常请求的 URL 是否一致- 请求参数是否一致- 请求头中 token 是否存在- 用户权限是否发生变化- 返回数据结构是否变化- 是否某条数据导致页面渲染异常- 最近是否发布过前端或后端代码- 是否修改过网关、Nginx、权限配置很多线上问题不是代码完全不可用而是某些特殊数据、特殊用户、特殊参数触发了异常。———## 六、如果是偶发问题重点看资源和性能如果页面不是每次刷新都卡住而是偶发出现就要重点考虑性能和资源问题。比如- 数据库慢查询- 数据库锁等待- 连接池不够用- Redis 响应慢- 线程池被打满- JVM Full GC- 下游服务偶发超时- 网关超时- 网络抖动这类问题一般需要结合监控系统来分析比如接口耗时、QPS、错误率、CPU、内存、GC、数据库连接数等指标。———## 七、面试回答模板面试时可以这样回答 如果页面刷新后一直显示 loading我会先用浏览器开发者工具判断问题范围。首先看 Console 有没有前端报错再看 Network 里接口有没有发出去、状态码是多少、是否 pending、响应内容 是否正常。 如果接口 pending 或返回 500我会根据请求路径、参数、时间点、traceId 去查后端日志看 请求是否进入 Controller是否卡在数据库、Redis、第三方接口或者线程池资源上。 如果接口返回 401 或 403我会重点排查 token、session、cookie 和权限问题因为刷新页面 后通常会重新获取用户信息和菜单权限。 如果接口返回 200 但页面仍然 loading就要看返回数据结构是否符合前端预期是否有空字段 或异常数据以及前端是否在异常分支中没有关闭 loading。 总体来说我会先区分是前端、网络还是后端问题再沿着请求链路逐层定位同时结合日志、监 控和链路追踪来确认具体原因。———## 八、总结页面刷新后一直转圈看似是一个简单的问题但背后可能涉及前端渲染、接口请求、登录权限、后端服务、数据库、缓存、网关等多个环节。这类场景题的核心不是猜答案而是体现排查思路1. 先看浏览器 Console 和 Network2. 再根据接口状态判断方向3. 后端结合日志和 traceId 排查链路4. 对比正常和异常请求5. 偶发问题重点看性能、资源和监控面试回答时只要能体现“先定位范围再逐层深入”的思路就能给面试官留下比较好的印象。