Vue 3 无法直接处理 HTTP 500 错误，真正的友好 500 页面需后端返回标准状态码、Nginx 等服务器拦截并返回静态页（如 public/500.html），前端则通过请求拦截和 unhandledrejection 监听做降级提示与跳转。
Vue 3 本身不处理 HTTP 500 这类后端错误——它属于服务端响应，前端无法“捕获并渲染 500 页面”；真正能展示友好 500 页面的，是部署时的 Web 服务器（如 Nginx、Apache）或云平台（如 Vercel、Cloudflare Pages）的静态错误页机制。但 Vue 应用可以在前端层面做两件事：一是拦截请求失败、展示用户友好的降级提示；二是配合后端和部署配置，让真实 500 错误发生时跳转到预设的静态错误页。
前端侧：统一处理 API 请求异常
这是你能直接控制的部分。推荐在封装的请求层（如 useRequest 或 axios 实例）中集中处理：
- 对 status >= 400 的响应，不直接 throw，而是返回标准化错误对象（含 code、message、retry 等字段）
- 全局监听未捕获的 Promise rejection（注意：仅适用于未被 .catch() 拦截的请求异常）：
window.addEventListener('unhandledrejection', event => { if (event.reason?.response?.status === 500) { // 触发全局错误状态，比如显示模态框或跳转到 /error useRouter().push('/error?code=500'); } }); - 在 /error 路由对应的组件里，不调用任何接口，只展示静态文案 + 返回首页按钮，避免二次出错
部署侧：让真实 500 触发静态错误页
关键不在 Vue 代码，而在你部署用的服务器配置：
Springboot Vue Builder
下载
从零开始编排 SpringBoot+Vue 全栈项目工作流，适用于新建全栈项目或完整脚手架请求，触发后依次调用 product‑spec‑builder（需求调研）等模块。
-
Nginx 示例：在 server 块中添加
error_page 500 /500.html; location = /500.html { internal; root /usr/share/nginx/html; }确保构建产物目录下存在 public/500.html（Vite 会自动将其复制到 dist 根目录） - Vercel / Netlify：在项目根目录放 public/500.html，平台会自动识别并接管 500 响应
- 注意：这个页面必须是纯静态 HTML（无 JS、不依赖 Vue Router），否则在服务端崩溃时根本无法加载
后端协同：确保错误可识别
前端友好页面的前提，是后端真正返回标准 500 状态码：
立即学习“前端免费学习笔记（深入）”；
- Spring Boot 等后端框架需关闭“500 错误自动跳转到 Whitelabel Error Page”，改用 ResponseEntity.status(500).body(...) 显式返回
- 避免后端把 500 包装成 200 + { code: 500 } —— 这会让前端永远收不到真实 500，也就触发不了 Nginx 的 error_page
- 跨域场景下，确保后端响应头包含 Access-Control-Allow-Origin，否则前端 fetch 会因 CORS 失败而无法读取 status
真正的“友好 500 页面”是前后端+部署三方协作的结果：后端发出标准状态码，Nginx 拦截并返回静态页，前端则负责在请求链路中提前兜底、避免白屏或无限 loading。单独靠 Vue 代码做不到完整覆盖。
