应主动检查 response.status 并分层处理：2xx 为业务成功，4xx 提示客户端问题，5xx 降级或重试；fetch 需手动判断状态码范围，axios 可用拦截器统一处理；协议层状态与业务状态须分离，超时等网络异常需单独捕获。
Ajax 请求中，不同 HTTP 状态码代表不同的服务端响应含义，不能只靠 success 或 then() 判断是否“成功”。关键在于主动检查 response.status，并按语义分类处理：2xx 视为业务成功，4xx 是客户端问题需提示用户，5xx 是服务端故障需降级或重试。
用 fetch 检查 status 并分层处理
fetch 默认不会因 4xx/5xx 抛错，必须手动判断 response.status：
- 状态码在 200–299 范围，才调用
response.json()解析数据 - 遇到 401（未登录）可跳转登录页；403（无权限）提示权限不足；404 显示“资源不存在”
- 500、502、503 等建议显示友好提示，并提供“重试”按钮，避免用户反复刷新
用 Axios 统一拦截状态码逻辑
Axios 的响应拦截器适合集中处理常见状态码：
- 在
axios.interceptors.response.use中检查response.status - 对 401 自动清空 token 并跳转登录；对 429（请求频繁）可暂停提交并倒计时
- 对 5xx 响应，可在拦截器里记录错误日志，并返回一个带
code: 'SERVER_ERROR'的标准化对象供上层判断
避免只依赖 statusText 或 success 字段
statusText 是服务端返回的描述文本（如 "Not Found"），不可靠；某些接口即使失败也返回 200 + 错误体（如 { code: 1001, msg: "参数错误" }）。正确做法是：
- 先看
response.status判断网络和协议层是否正常 - 再解析响应体，检查业务字段（如
code === 0才算业务成功） - 把协议层状态和业务状态分开处理，避免混淆
超时和网络异常要单独捕获
状态码只反映 HTTP 响应，不包含网络中断、DNS 失败、请求超时等情况：
- fetch 需配合
AbortController设置超时，被中止时会抛AbortError - Axios 的
timeout配置触发时，错误对象有code: 'ECONNABORTED' - 这些情况不属于 HTTP 状态码范畴，但用户体验上同样需要明确提示，比如“网络开小差了，请稍后再试”
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
