前端必须依据Retry-After响应头决定重试时机，其值为整数秒或HTTP日期字符串，需兼容两种格式并转为毫秒延迟；推荐后端统一用整数秒，前端通过headers.get('Retry-After')提取、判断格式、计算等待时间、限制重试次数。
当Laravel后端触发限流（如使用RateLimiter或throttle中间件）并返回429状态码时，前端必须依据响应头中的Retry-After字段决定何时发起下一次请求，否则可能持续失败或造成请求风暴。
理解Retry-After响应头的两种格式
Retry-After值可能是整数秒，也可能是HTTP日期字符串，取决于Laravel版本和限流配置方式。
若返回Retry-After: 60，表示客户端应在60秒后重试；若返回Retry-After: Wed, 06 Aug 2026 10:45:30 GMT，则需解析该时间戳并计算本地等待毫秒数。
Laravel 9+ 默认使用整数秒格式；但若通过Response::withHeaders(['Retry-After' => $date])手动设置HTTP日期，则前端必须兼容两种格式——否则在Chrome中可能正常，在Safari中因Date构造失败导致重试逻辑崩溃。
立即学习“前端免费学习笔记（深入）”；
后端配置Retry-After的三种方式
方法一：使用内置throttle中间件（推荐）
在app/Http/Kernel.php中为路由添加throttle:60,1，Laravel自动注入整数型Retry-After，无需额外代码。
方法二：自定义RateLimiter并显式返回Retry-After
在bootstrap/app.php或服务提供者中注册限流器时，调用$limiter->hit($key, $decaySeconds)后，用now()->addSeconds($decaySeconds)->timestamp算出到期时间戳，再通过response()->json(...)->header('Retry-After', $seconds)强制写入整数秒。
【注意】不要直接写HTTP日期字符串给Retry-After——除非你确认所有前端环境都支持new Date('Wed, 06 Aug 2026 10:45:30 GMT')
方法三：全局异常处理器中拦截ThrottleRequestsException
在app/Exceptions/Handler.php的render()方法里，判断$exception instanceof ThrottleRequestsException，然后用$exception->getHeaders()['Retry-After'] ?? 60获取原始值，再统一覆写为整数格式返回。
前端读取并解析Retry-After的可靠实现
第一步：从fetch响应中提取Retry-After头
使用response.headers.get('Retry-After')获取原始值，不要用response.headers.get('retry-after')——HTTP头名大小写敏感，某些CDN会标准化为首字母大写。
第二步：判断格式并转为毫秒等待值
用!isNaN(Number(retryAfter))检测是否为整数秒；否则尝试new Date(retryAfter).getTime() - Date.now()，若结果为NaN则fallback到默认1000ms。
第三步：执行延迟重试
用setTimeout(() => fetch(...), Math.max(100, waitMs))发起重试，【Math.max(100, waitMs)防止waitMs为负数导致立即重试】。
第四步：限制重试次数
在请求选项中携带retryCount: (options.retryCount || 0) + 1，并在重试前判断options.retryCount >= 3则抛出错误终止循环。
