响应拦截器应统一捕获503状态码或code:5001业务码并跳转/maintenance页，同时配置对应路由与精简页面，避免重复跳转。
当服务器处于维护状态（例如返回 HTTP 状态码 503 Service Unavailable 或自定义业务码如 code: 5001），响应拦截器可以统一捕获并跳转到专门的「系统维护中」公告页面，而不是让错误散落在各个组件里处理。
识别维护状态的响应
后端通常会在维护期间返回明确标识，常见方式有两种：
- HTTP 状态码为 503：标准语义即“服务不可用”，最推荐使用
-
业务响应体含特定字段：例如
{ code: 5001, msg: "系统维护中，请稍后再试" }
在响应拦截器中同时判断这两类情况，覆盖更全面。
在响应拦截器中跳转公告页
修改你的 Axios 响应拦截器逻辑（如 src/utils/request.ts）：
立即学习“前端免费学习笔记（深入）”；
- 检查
error.response?.status === 503 - 或检查
response.data?.code === 5001（注意需先确保response.data存在且非空） - 匹配成功后，调用
router.push('/maintenance') - 记得
return Promise.reject(...)避免后续 .then 处理执行
示例片段：
service.interceptors.response.use(
response => {
// 正常响应：先判断是否为维护码
const { code, msg } = response.data || {}
if (code === 5001) {
router.push('/maintenance')
return Promise.reject(new Error(msg || '系统维护中'))
}
return response.data
},
error => {
if (error.response?.status === 503) {
router.push('/maintenance')
return Promise.reject(error)
}
// 其他错误走常规处理（如 401、网络异常等）
return handleRequestError(error)
}
)
配置独立的维护公告路由与页面
确保项目中已注册路径为 /maintenance 的路由，指向一个静态公告页：
- 页面可包含友好文案、倒计时（如已知恢复时间）、刷新按钮、客服联系方式
- 建议禁用该页面的导航栏、侧边栏等交互元素，避免用户误操作离开
- 可配合
meta: { layout: 'empty' }使用精简布局
避免重复跳转与用户体验细节
跳转前加一层轻量判断，防止多次触发：
- 记录当前是否已在维护页（如用
router.currentRoute.value.path === '/maintenance'） - 若已在此页，不再重复
push，可改为replace或直接忽略 - 可配合全局状态（如 Pinia store）标记「维护模式开启」，用于其他逻辑联动（如禁用按钮、隐藏表单）
