在 Java 后端面试中，经常会遇到一些"线上问题排查类"的场景题。比如：
> 一个页面之前显示正常，但是刷新之后突然出现不断旋转的加载图标，一直无法加载完成。你会怎
> 么排查？
这类题目考察的不只是某个具体知识点，而是候选人是否具备完整的问题定位思路。回答时不要一上
来就猜"是不是后端接口挂了"，而应该按照链路逐层排查。
一、先明确问题范围
页面一直转圈，本质上说明页面处于 loading 状态没有结束。
常见原因大致可以分为三类：
-
前端代码报错，导致页面渲染中断
-
接口请求没有正常返回，页面一直等待数据
-
接口返回了，但返回数据异常，前端没有正确关闭 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 判断是接口问题，就需要进入后端排查。
排查后端时，可以按照下面的链路看：
-
请求有没有进入网关或 Nginx
-
请求有没有转发到后端服务
-
Controller 有没有接收到请求
-
Service 层业务逻辑是否正常
-
数据库、Redis、MQ、第三方接口是否正常
-
接口是否在某一步出现超时或异常
对于 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。
>
> 总体来说，我会先区分是前端、网络还是后端问题，再沿着请求链路逐层定位，同时结合日志、监
> 控和链路追踪来确认具体原因。
八、总结
页面刷新后一直转圈，看似是一个简单的问题，但背后可能涉及前端渲染、接口请求、登录权限、后
端服务、数据库、缓存、网关等多个环节。
这类场景题的核心不是猜答案，而是体现排查思路：
-
先看浏览器 Console 和 Network
-
再根据接口状态判断方向
-
后端结合日志和 traceId 排查链路
-
对比正常和异常请求
-
偶发问题重点看性能、资源和监控
面试回答时，只要能体现"先定位范围，再逐层深入"的思路，就能给面试官留下比较好的印象。