出差路上用 AI 写了个应用，演示完之后全是报错

出差期间没闲着，利用碎片时间折腾出了一个小应用，今天在团队会议上做了 Demo，结果反馈居然出奇地好，甚至有同事直接问能不能把这套东西集成到他们接下来的项目里。但这种“顺风顺水”的感觉没持续多久，回到工位准备加功能时，代码就开始疯狂报错了。

最离谱的是，我压根没动过任何权限相关的逻辑，API 却先是报 Rate Limited（频率限制），紧接着直接跳 Unauthorized（未授权）。这种莫名其妙的报错在开发过程中最折磨人，尤其是当你确定逻辑没变的时候，往往是环境或者鉴权 Token 自动失效导致的。

不过换个角度想，这种“突发状况”其实是做错误处理（Error Handling）最好的实战机会。我直接趁机把代码里的异常捕获逻辑重构了一下，把这些随机出现的报错都纳入了更稳健的响应机制里。

针对这种 API 报错，我现在的处理工作流大概是这样的：

异常捕获与重试逻辑配置

不再只是简单地 try...catch，而是针对不同的状态码做差异化处理，防止因为一次网络波动或限流导致整个应用挂掉。

async function fetchWithRetry(url, options, retries = 3) {
  try {
    const response = await fetch(url, options);
    
    if (response.status === 429) {
      // 处理频率限制，等待一段时间后重试
      const retryAfter = response.headers.get('Retry-After') || 2;
      console.warn(`Rate limited. Retrying after ${retryAfter}s...`);
      await new Promise(res => setTimeout(res, retryAfter * 1000));
      return fetchWithRetry(url, options, retries - 1);
    }

    if (response.status === 401) {
      // 处理未授权，尝试刷新 Token 或重新登录
      console.error("Unauthorized! Triggering re-authentication flow...");
      await refreshToken(); 
      return fetchWithRetry(url, options, retries - 1);
    }

    if (!response.ok) {
      throw new Error(`HTTP error! status: ${response.status}`);
    }

    return await response.json();
  } catch (error) {
    if (retries > 0) {
      return fetchWithRetry(url, options, retries - 1);
    }
    throw error;
  }
}

这种实战经验告诉我，写代码时不要假设 API 永远会按预期响应。不管是出差时临时赶出来的代码，还是正式上线的功能，把 Error Response 的硬度（Hardening）做足，比单纯追求功能实现要重要得多。接下来还得继续修补这个应用，顺便把最近在 Bandcamp 上搞的一些项目也整理出来。