Google Apps Script中UrlFetchApp.fetchAll的错误捕获与重试实现方法

• UrlFetchApp.fetchAll 的并发调度能力相比逐次单调用UrlFetchApp.fetch，可大幅降低多请求场景的整体执行耗时。但请求规模较大时，极易触发服务端临时类错误（典型场景为429限流、500/503服务端临时异常），这类错误绝大多数情况下无需调整请求参数，仅需对对应失败请求重新发起请求即可解决。
• 经公开基准测试验证，UrlFetchApp.fetchAll 返回的HTTPResponse[]结果数组与传入的请求数组不保证严格顺序对齐。如果直接靠数组索引做匹配，根本无法定位失败响应对应的原始请求URL与参数，也就无法基于单请求调用逻辑对失败请求做精准重试。
• 无任何匹配逻辑的基础调用写法存在天然缺陷：

  let requests = [
    { url: '', muteHttpExceptions: true }, 
    { url: '', muteHttpExceptions: true }
  ];
  let responses = UrlFetchApp.fetchAll(requests);
  

核心修复思路 #

• 不要直接将原始请求对象传入fetchAll，为每一条请求绑定全局唯一的可追溯标识，将标识嵌入请求的自定义Header中随请求一同发送
• 拿到返回的响应集合后，完全放弃数组索引匹配逻辑，通过提取每个响应携带的请求标识，与预先维护的请求池做一一映射
• 遍历全量响应，筛选出状态码为429、500、503的临时错误响应，根据存储的请求标识从请求池中捞出对应原始请求，单独使用UrlFetchApp.fetch发起重试即可

最小可适配代码示例 #

// 为每个原始请求绑定唯一ID，生成可追溯的请求池
const requestPool = requests.map((req, idx) => ({
  ...req,
  headers: {
    ...(req.headers || {}),
    "x-unique-req-id": `batch_req_${idx}`
  }
}))

const responses = UrlFetchApp.fetchAll(requestPool)

// 按标识匹配失败请求，完全不依赖数组返回顺序
const failedRequestList = responses
  .filter(res => [429, 500, 503].includes(res.getResponseCode()))
  .map(errRes => {
    const reqId = errRes.getHeaders()["x-unique-req-id"]
    return requestPool.find(item => item.headers["x-unique-req-id"] === reqId)
  })

内容的提问来源于stack exchange，提问作者Viewed