本文旨在解决React应用中使用`fetch` API时遇到的CORS策略问题，特别是当请求需要授权时。常见的错误包括将`mode: 'no-cors'`错误地置于`headers`对象中，以及使用不正确的授权头部字段（如`Authentication`而非`Authorization`）。教程将详细阐述如何正确配置`fetch`请求，包括将`mode`属性放置在正确位置，并强调使用标准的`Authorization: Bearer
理解CORS与预检请求
跨域资源共享（CORS）是一种浏览器安全功能，旨在限制网页从不同域请求资源。当浏览器检测到一个跨域请求，并且该请求包含了某些“非简单”的特性（例如自定义HTTP头、PUT/DELETE方法、特定的Content-Type等），它会在实际请求发送前，先发送一个“预检请求”（Preflight Request），通常是一个OPTIONS方法。
预检请求的目的是询问服务器，是否允许实际的请求。服务器会通过响应头（如Access-Control-Allow-Origin、Access-Control-Allow-Methods、Access-Control-Allow-Headers等）告知浏览器其CORS策略。如果服务器的响应表明不允许某个特定的头部字段（如本例中的authentication），浏览器就会阻止实际请求的发送，并抛出Access to fetch... has been blocked by CORS policy: Request header field authentication is not allowed by Access-Control-Allow-Headers in preflight response.这样的错误。
常见的Fetch配置误区与纠正
在React应用中使用fetch API进行跨域请求时，尤其涉及到授权，开发者常犯以下两个错误：
-
mode: 'no-cors' 的错误使用和位置：
- 误区： 将mode: 'no-cors'放在headers对象内部。
- 纠正： mode属性是fetch请求选项的顶级属性，与headers平级。
- 为什么no-cors不适用： no-cors模式旨在发送不透明请求，即浏览器不会检查响应的CORS策略。虽然这可能避免CORS错误，但响应对象会变得“不透明”（opaque），你无法访问响应体、状态码等，这对于需要处理API响应的应用来说是无用的。对于需要授权的API请求，通常应使用默认的cors模式，并确保服务器正确配置了CORS。
-
授权头部字段拼写错误：
- 误区： 使用Authentication作为授权头部字段。
- 纠正： 标准的HTTP授权头部字段是Authorization。
- 标准格式： 对于Bearer Token，其格式应为Authorization: Bearer <your_token>。
正确的Fetch请求配置示例
结合上述纠正，以下是修复后的React组件代码，展示了如何正确配置带有授权头的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
// mode: 'cors', // 默认就是'cors'，通常不需要显式指定
headers: {
// 正确的授权头部字段是 'Authorization'
Authorization: 'Bearer my_token',
// 其他可能需要的头部，例如 Content-Type
// 'Content-Type': 'application/json',
},
});
if (!response.ok) {
// 处理HTTP错误，例如401 Unauthorized, 403 Forbidden等
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;代码解析与改进点：
- mode属性移除： 移除了mode: 'no-cors'，因为fetch的默认模式就是cors，这允许浏览器执行CORS检查并正常处理响应。
- Authorization头部： 将Authentication更正为标准的Authorization，并采用Bearer <token>的标准格式。
- 异步/等待 (async/await)： 将.then()链式调用改为async/await语法，使异步代码更易读和维护。
- 错误处理： 添加了try...catch块来捕获网络错误和API返回的非2xx状态码，提高了代码的健壮性。
注意事项与进一步排查
即使客户端代码配置正确，CORS问题仍然可能出现。这通常意味着服务器端的CORS配置存在问题。
-
服务器端CORS配置：
- API服务器必须在响应头中包含正确的CORS策略，例如：
- Access-Control-Allow-Origin: http://localhost:3000 (或*，但不推荐用于生产环境)
- Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
- Access-Control-Allow-Headers: Authorization, Content-Type (确保包含你发送的所有自定义头部)
- 对于预检请求（OPTIONS方法），服务器必须正确响应，并且这些CORS头部必须包含在OPTIONS请求的响应中。
- API服务器必须在响应头中包含正确的CORS策略，例如：
-
浏览器开发者工具：
- 打开浏览器的开发者工具（通常按F12），切换到“网络”（Network）选项卡。
- 重新加载页面并观察请求。你会看到一个OPTIONS请求（预检请求），紧接着是你的实际GET请求。
- 检查OPTIONS请求的响应头，确保Access-Control-Allow-Headers包含了Authorization。
- 检查实际GET请求的响应头，确保Access-Control-Allow-Origin与你的前端源匹配。
Token有效性： 确保你使用的my_token是有效的、未过期的，并且拥有访问该API的权限。
总结
解决React中fetch API的CORS策略问题，特别是涉及授权时，关键在于理解CORS机制，并正确配置客户端的请求。这包括将mode属性放置在正确位置（通常不显式指定，让其默认为cors），以及使用标准的Authorization头部字段来传递认证令牌。同时，不要忽视服务器端的CORS配置，它是确保跨域通信成功的另一半关键。通过仔细检查客户端代码和服务器响应，可以有效地诊断并解决CORS相关问题。
