fetch发起请求需注意：默认不带cookie，4xx/5xx不自动reject，json需设content-type，带cookie需credentials: 'include'且后端配access-control-allow-credentials；跨域预检失败需检查后端是否返回正确的access-control-*响应头。
JavaScript 与后端 API 交互主要靠 fetch 或 XMLHttpRequest，跨域问题不是前端能“解决”的，而是需要前后端协同配置；前端唯一能做的，是正确发起请求并理解错误来源。
用 fetch 发起 GET/POST 请求时要注意什么？
现代项目首选 fetch，但它默认不带 cookie，且对 4xx/5xx 状态码不会抛错——这点常被忽略。
-
fetch返回 Promise，但仅在网络失败时 reject；HTTP 错误状态（如 401、500）仍会 resolve，需手动检查response.ok或response.status - 发送 JSON 数据时，必须设置
headers: { 'Content-Type': 'application/json' }，否则后端可能解析失败 - 携带 Cookie 需显式加
credentials: 'include'，且后端响应头必须有Access-Control-Allow-Credentials: true
fetch('/api/user', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
credentials: 'include',
body: JSON.stringify({ name: 'Alice' })
})
.then(res => {
if (!res.ok) throw new Error(`HTTP ${res.status}`);
return res.json();
})
.catch(err => console.error('请求失败:', err));
浏览器报 No 'Access-Control-Allow-Origin' header 怎么办？
这是典型的跨域预检失败，说明请求触发了 CORS 预检（比如带自定义 header、非简单方法），但后端没返回必要响应头。
- 简单请求（GET/HEAD/POST + 纯文本 Content-Type）只发一次请求；含
Authorization、Content-Type: application/json等会触发预检（OPTIONS 请求） - 后端必须在预检响应中返回：
Access-Control-Allow-Origin（不能为*当credentials: 'include'时）、Access-Control-Allow-Methods、Access-Control-Allow-Headers - 前端无法绕过这个限制——禁用浏览器安全策略只适用于本地开发调试（如 Chrome 启动参数
--disable-web-security），不可用于生产
开发时如何快速验证跨域配置是否生效？
别只看前端控制台，重点查 Network 面板里 OPTIONS 请求的响应头。
立即学习“Java免费学习笔记（深入）”；
- 在浏览器开发者工具的 Network 标签页中，找到以
OPTIONS方法发出的请求，点开 Response Headers，确认是否存在Access-Control-Allow-Origin等字段 - 如果 OPTIONS 请求返回 404 或 500，说明后端路由没处理预检，不是前端代码问题
- 用 curl 模拟预检更直接：
curl -H "Origin: http://localhost:3000" \ -H "Access-Control-Request-Method: POST" \ -H "Access-Control-Request-Headers: Content-Type" \ -X OPTIONS -I http://your-api.com/api/data观察返回头是否包含对应Access-Control-*字段
跨域的本质是浏览器的同源策略限制，不是 bug 也不是前端缺陷。真正卡住人的地方，往往在于后端漏配 Access-Control-Allow-Credentials 却又前端硬加 credentials: 'include'，或者预检响应里 Access-Control-Allow-Origin 写成了 * 但实际需要精确匹配协议+域名+端口。
