React无服务器站点fetch遇cors-anywhere代理403的CORS解决方法

两类报错存在直接的因果关联，并非独立问题：

• 第一类403报错来自cors-anywhere.herokuapp.com公共代理的规则调整：该服务当前已启用请求校验机制，无有效演示额度的请求会直接被拦截，无法正常返回目标地址的taplist.xml内容
• 第二类Cannot read property 'value' of undefined属于衍生错误：原有代码未对fetch返回的响应做合法性校验，拿到空响应/错误页面内容后直接进入XML解析流程，找不到预期的XML节点时就会抛出未捕获的Promise异常

优化现有fetch逻辑的健壮性 #

原有请求逻辑的容错性为零，调整核心点包括：

• 用try/catch块包裹整个请求、解析流程，避免未捕获的Promise报错
• 收到响应后先校验请求状态：仅当响应状态为成功、返回内容匹配XML格式时，才进入后续解析流程，否则直接抛出明确的错误提示
• 解析XML后先校验目标节点是否存在，不存在则渲染空酒单状态，不要直接读取节点的value属性

调整后的参考代码片段：

async componentDidMount() {
  try {
    // 替换为可用的代理地址、目标酒单地址
    const requestUrl = `${proxyBaseUrl}${rawTaplistUrl}`;
    const response = await fetch(requestUrl);

    // 拦截非成功状态的响应
    if (!response.ok) {
      throw new Error(`酒单请求失败，状态码：${response.status}`);
    }

    const xmlContent = await response.text();
    const parser = new DOMParser();
    const xmlDoc = parser.parseFromString(xmlContent, "text/xml");

    // 校验节点是否存在，避免空值读取报错
    const beerItemNodes = xmlDoc.getElementsByTagName('beer');
    if (!beerItemNodes.length) {
      this.setState({ tapList: [], isLoading: false });
      return;
    }

    // 正常解析酒单数据并更新状态
    const parsedTapList = Array.from(beerItemNodes).map(node => ({
      // 原有酒单解析逻辑
    }));
    this.setState({ tapList: parsedTapList, isLoading: false });
  } catch (err) {
    // 捕获全流程异常，渲染错误提示
    this.setState({ error: err.message, isLoading: false });
  }
}

替代CORS代理的可选方向 #

公共代理本质是无服务保障的临时转发通道，普遍存在调用配额、随时封禁的问题，仅适合临时救急，可选择的替代路径包括：

• 直接替换同类公共代理地址，无需额外开发即可快速恢复基础功能
• 依托网站部署平台的内置重写规则，配置本地路径的转发代理，不依赖第三方公共服务，稳定性远高于零散的公共代理
• 基于网站同环境的无服务器函数实现轻量转发逻辑，代码量极少，可完全掌控代理的可用性

长期稳定的修复方案 #

由于酒吧酒单是固定地址的静态XML资源，长期来看完全可以规避跨域需求：

• 定期将最新的taplist.xml同步到网站自身的静态资源目录，前端直接请求本地静态文件，从根源上消除跨域问题
• 若酒单更新频率较高，可配置平台定时任务每日拉取最新XML内容存储到静态资源目录，前端访问无任何跨域成本

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