在 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. 请求有没有进入网关或 Nginx
2. 请求有没有转发到后端服务
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 和 Network
2. 再根据接口状态判断方向
3. 后端结合日志和 traceId 排查链路
4. 对比正常和异常请求
5. 偶发问题重点看性能、资源和监控
面试回答时，只要能体现“先定位范围，再逐层深入”的思路，就能给面试官留下比较好的印象。
