本文旨在解决React应用中，使用Fetch API访问外部API时遇到的CORS策略问题，特别是涉及授权头部（Authorization）的场景。核心问题通常源于fetch请求选项的误用，如将mode: 'no-cors'错误放置于headers对象内，以及将授权头部错误命名为Authentication而非正确的Authorization。教程将指导开发者正确配置fetch请求，确保授权令牌的有效传递，从而成功绕过CORS限制并获取数据。
在现代Web开发中，前端应用（如基于React的项目）经常需要与部署在不同域的后端API进行交互。这种跨域请求受限于浏览器的同源策略（Same-Origin Policy），为了安全起见，浏览器会阻止来自不同源的HTTP请求。跨域资源共享（CORS, Cross-Origin Resource Sharing）机制正是为了解决这一问题而生，它允许服务器明确地授权特定源的跨域请求。
当我们在React组件中使用fetch API向外部API发送带有授权信息的请求时，如果配置不当，很可能会遇到CORS策略错误，例如常见的Request header field authentication is not allowed by Access-Control-Allow-Headers in preflight response。这个错误通常意味着浏览器在发送实际请求之前，会先发送一个“预检请求”（preflight request，通常是OPTIONS方法），以确认服务器是否允许该源、该方法和该自定义头部（如Authorization）的请求。如果服务器的响应头中不包含相应的许可，浏览器就会阻止后续的实际请求。
fetch API中的常见配置误区
在处理带有授权头部的跨域请求时，开发者常犯以下两个错误：
1. mode 属性的错误放置与不当使用
fetch API的mode属性用于控制请求的CORS模式。常见的模式包括cors（默认）、no-cors和same-origin。
一个常见的错误是将mode属性放置在headers对象内部，如下所示：
// 错误示例：mode 属性位置不正确
fetch('https://api.airtable.com/v0/my_data_base', {
headers: {
mode: 'no-cors', // 错误：mode 不属于 headers
Authentication: 'Bearer my_token',
},
})mode属性是fetch请求的顶级选项之一，应与headers对象平级。
此外，mode: 'no-cors'虽然听起来可以绕过CORS，但它有严格的限制。当使用no-cors模式时，请求会被发送，但浏览器会阻止JavaScript代码访问响应内容（例如，你无法读取响应的状态码或正文）。这对于需要处理API响应的场景（如获取数据）是不可接受的。对于需要发送自定义头部（如Authorization）的请求，通常应使用默认的mode: 'cors'，并确保后端API正确配置了CORS响应头。
2. 授权头部名称的拼写错误
另一个常见但关键的错误是授权头部的名称拼写。标准的HTTP授权头部是Authorization，而不是Authentication。
// 错误示例：授权头部名称拼写错误
fetch('https://api.airtable.com/v0/my_data_base', {
headers: {
Authentication: 'Bearer my_token', // 错误：应为 Authorization
},
})当浏览器发送预检请求时，它会检查服务器的Access-Control-Allow-Headers响应头中是否包含了所有自定义请求头部。如果前端发送的是Authentication，而后端只配置了允许Authorization，那么预检请求就会失败。
正确配置 fetch API进行跨域授权请求
结合上述分析，修复这些问题相对直接。以下是正确的fetch请求配置示例：
import { FC, useEffect } from 'react';
const Collection: FC = () => {
useEffect(() => {
const fetchData = async () => {
try {
const response = await fetch('https://api.airtable.com/v0/my_data_base', {
method: 'GET', // 明确指定请求方法，默认为GET
headers: {
'Content-Type': 'application/json', // 通常需要指定内容类型
'Authorization': 'Bearer my_token', // 正确的授权头部名称
},
// mode: 'cors' 是默认值，通常不需要显式设置
});
if (!response.ok) {
throw new Error(`HTTP error! status: ${response.status}`);
}
const data = await response.json();
console.log(data);
} catch (error) {
console.error("Fetch error:", error);
}
};
fetchData();
}, []); // 依赖数组为空，只在组件挂载时执行一次
return <div>Collection Page Component</div>;
};
export default Collection;代码解析：
- Authorization: 'Bearer my_token': 这是最关键的修正。将授权头部名称从Authentication更正为标准的Authorization。Bearer是令牌类型，后面跟着实际的访问令牌。
- mode 属性: 在这个修正后的代码中，mode属性被省略了。这是因为fetch的默认mode就是'cors'，它允许发送自定义头部并接收响应。对于需要授权的跨域请求，'cors'模式是正确的选择。
- Content-Type: 虽然不是直接解决CORS问题的关键，但为了API交互的规范性，通常会包含Content-Type头部，例如'application/json'，表明请求体的内容类型。
- 异步/等待 (async/await): 为了更好地处理异步操作和错误，这里将.then().catch()链式调用改写为更现代的async/await语法。
- 错误处理: 增加了对response.ok的检查，以便在HTTP状态码表示错误时抛出异常，并使用try...catch捕获潜在的网络或解析错误。
注意事项与最佳实践
- 服务器端CORS配置: 即使前端fetch配置正确，如果后端API服务器没有正确配置CORS响应头（例如，Access-Control-Allow-Origin、Access-Control-Allow-Methods、Access-Control-Allow-Headers），CORS问题仍然会存在。请确保API提供者已正确配置其服务器。
- 令牌安全: 访问令牌（my_token）不应硬编码在前端代码中。在实际应用中，它们通常通过登录流程动态获取，并安全地存储（例如，使用HTTP Only的Cookie或Web Storage，并注意XSS风险）。
- 预检请求: 带有自定义头部（如Authorization）的跨域请求，浏览器会先发送一个OPTIONS预检请求。服务器必须正确响应这个预检请求，告知浏览器允许的源、方法和头部。
- 开发环境代理: 在开发环境中，如果后端API无法修改CORS配置，可以考虑使用开发服务器（如Webpack Dev Server或Vite）的代理功能，将前端请求转发到后端，从而绕过浏览器的CORS限制。
总结
解决React中fetch API的CORS授权头部问题，关键在于理解CORS机制和fetch请求选项的正确使用。核心修正包括：将授权头部从Authentication更正为标准的Authorization，并确保mode属性被正确理解和使用（通常默认的'cors'模式即可，避免将'no-cors'错误放置于headers中）。通过这些调整，开发者可以确保授权令牌正确传递，从而成功与需要认证的外部API进行交互。同时，不要忘记后端API的CORS配置也是解决问题的关键一环。
