项目缺少请求速率控制，处理多章节时容易触发 部分AI 服务 429 错误

[taozhe6]

问题描述

项目在处理多章节书籍时，会快速连续发送多个 AI API 请求，容易触发各 AI 服务商的速率限制，导致 429 (Too Many Requests) 错误。

具体问题

1. 缺少请求间隔控制

• 处理多个章节组时，请求之间没有延迟
• 组内多个章节可能同时或快速连续调用 AI API
• 没有队列机制控制并发请求数量

2. 缺少错误处理机制

• 遇到 HTTP 429 错误时直接抛出异常
• 没有解析 Retry-After 响应头
• 没有自动重试和指数退避策略

3. 影响用户体验

• 大书籍处理容易中断失败
• 用户需要手动重试整个流程
• 没有友好的错误提示

技术细节

相关代码位置：

• src/services/aiService.ts - AI 请求处理
• src/services/bookProcessingService.ts - 章节批处理
• src/pages/SummaryPage.tsx - 处理流程控制

当前处理流程：

for (const group of groups) {
  // 快速连续调用，没有延迟
  await bookProcessingService.processSummaryGroup(...)
}

建议的改进方案

1. 请求速率控制

• 添加请求队列机制，限制并发数（如同时最多 2-3 个请求）
• 在请求间增加可配置的延迟（如 1-3 秒）
• 支持不同 AI 服务商的不同速率限制配置

2. 智能错误处理

• 检测 HTTP 429 状态码
• 解析 Retry-After 响应头，自动等待指定时间
• 实现指数退避重试策略

3. 用户友好功能

• 显示"请求频繁，正在等待重试..."的提示
• 显示预计等待时间和重试进度
• 提供取消和手动重试选项

4. 配置选项

• 允许用户自定义请求频率设置
• 针对不同 AI 服务商的预设配置
• 支持开关自动重试功能

实现建议

可以考虑在 aiService.ts 中添加：

class RequestQueue {
  private queue: Array<() => Promise<any>> = []
  private running:  number = 0
  private maxConcurrent: number = 2
  private minInterval: number = 1000 // 1秒

  async add<T>(request: () => Promise<T>): Promise<T> {
    // 队列和速率控制逻辑
  }

  private async handleRateLimit(error: any) {
    // 429 错误处理和重试逻辑
  }
}

这个改进能显著提升项目在处理大书籍时的稳定性和用户体验。

[SSShooter]

不同模型供应商对速率限制的返回都不一样，所以比较难统一实现