应统一在请求拦截层处理非2xx状态码，提取message字段映射为友好提示，调用toast类轻量弹窗展示，401等强干预场景升级为带操作引导的确认弹窗，并脱敏展示、保留控制台调试信息。
当接口返回非 2xx 状态码（比如 401、403、500、502 等）时，不能只靠 catch 网络错误来覆盖——很多异常响应其实是成功收到了 HTTP 响应，只是状态码表明业务失败。要给出友好的弹窗，关键在于：拦截响应、识别状态码、映射为用户能理解的提示，并统一触发 UI 层弹窗。
在请求层统一拦截响应状态码
使用 fetch 或 axios 时，别等业务代码手动检查 response.status。应在请求封装层集中处理：
-
axios 示例：用
response interceptor拦截所有响应 - 对
status = 300的响应，不直接抛错，而是提取后端可能返回的message字段，再 fallback 到预设文案 - 避免在每个 API 调用后重复写
if (res.status === 403) showTip('权限不足')
按状态码分类映射友好提示文案
不同状态码代表不同问题，应区别对待，而不是全显示“请求失败”：
Java Development Manual
下载
Java开发手册规约集合，基于阿里巴巴Java开发手册（嵩山版）。 涵盖7大维度：编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约。 当用户需要：(1) 编写或审查Java代码 (2) 检查命名/代码规范 (3) 处理异常和日志 (4) 编写单元测试 (5) 安全编码 (6) 数据库设...
- 401 → “登录已过期，请重新登录” + 自动跳转登录页或弹出登录框
- 403 → “您没有权限执行此操作”（不暴露后端路径或角色细节）
- 404 → “请求的资源不存在”（慎用，优先排查前端路由或参数拼写）
- 500 / 502 / 503 → “服务暂时不可用，请稍后再试”（避免说“服务器炸了”之类不专业表述）
-
非标准业务码（如 { code: 1001, msg: "库存不足" }） 也应在此统一提取
msg并展示
调用轻量弹窗组件，避免阻塞主流程
弹窗建议用非模态、自动关闭的 toast 类型，体验更轻：
- 不要用
alert()—— 会阻塞 JS 执行，且样式无法定制 - 推荐封装一个
showToast(message, type = 'error')函数，内部调用 UI 库（如 Element Plus 的ElMessage、Ant Design Vue 的message.error，或原生 DOM 实现） - 对 401 这类需强干预的场景，可升级为确认弹窗或 Modal，但需明确操作引导（如“去登录”按钮）
补充：隐藏敏感信息，兼顾调试与用户体验
面向用户展示的文案必须脱敏，但开发时仍需保留上下文用于排查：
- 生产环境弹窗只显示友好提示；控制台仍可
console.warn输出完整响应（含 URL、status、data） - 可在请求配置中加
__debug: true标记，触发更详细的错误面板（仅限测试环境） - 避免把后端堆栈、数据库错误、内部路径等直接透出到前端弹窗
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
