网络抖动导致的瞬时报错本质是临时性故障，需识别可恢复性、主动干预重试并避免副作用：一、按错误类型分级重试；二、采用指数退避+随机抖动控制节奏；三、非幂等请求须通过x-request-id实现幂等；四、结合navigator.online前置拦截。
网络抖动导致的瞬时报错（如 ERR_NETWORK、ETIMEDOUT、503/504 等）本质是临时性故障，不是业务逻辑错误。处理核心不是“拦截错误”，而是“识别可恢复性 + 主动干预重试 + 避免副作用”。
一、精准识别哪些错误值得重试
盲目重试会放大问题。需按错误类型分级判断：
-
必须重试：网络层中断类 ——
ERR_NETWORK、ERR_CONNECTION_TIMEOUT、ETIMEDOUT、ENETDOWN、ECONNRESET -
选择性重试：服务端临时错误 ——
503 Service Unavailable、504 Gateway Timeout、429 Too Many Requests（注意：500 和 400 通常不重试） -
禁止重试：客户端错误或永久失败 ——
400 Bad Request、401 Unauthorized、403 Forbidden、404 Not Found、409 Conflict
二、用指数退避+随机抖动控制重试节奏
固定间隔重试（如每次等1秒）在弱网下易引发请求雪崩。应采用动态延迟：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 首次重试延迟：1000 ± 500ms（加随机偏移，避免集群同步冲击）
- 后续延迟：取
Math.min(1000 * Math.pow(2, attempt), 30000)，上限 30 秒 - 每次再叠加当前延迟值 ±50% 的随机抖动，进一步分散压力
三、保障非幂等请求的安全性
对 POST、PUT 等非幂等操作，重复提交会导致数据异常（如重复下单）。必须引入幂等控制：
- 前端生成唯一请求 ID（如
crypto.randomUUID()），通过X-Request-ID请求头透传 - 后端依据该 ID 去重或幂等落库，前端无需关心是否成功，只管发一次
- 若重试时发现原请求 ID 已存在响应缓存，直接返回历史结果，不发新请求
四、配合连接状态做前置拦截
在网络彻底断开时强行重试毫无意义，还浪费资源：
- 发起请求前检查
navigator.onLine === false，直接跳过并提示“请检查网络” - 监听
window.addEventListener('offline', ...)，暂停所有自动重试队列 - 收到
online事件后，恢复挂起的请求（或提示用户手动重试）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
