fetch 是现代浏览器中替代 XMLHttpRequest 的首选，返回 Promise 且语法简洁，但默认不携带 cookie、不自动拒绝非 2xx 响应，需手动检查 response.ok、设置 credentials: 'include'、指定 Content-Type，并自行封装超时；CORS 错误源于浏览器预检拦截，需确认请求是否触发 OPTIONS、响应头是否正确配置 Access-Control-Allow-Origin；开发期可用 Vite/Webpack 代理绕过跨域，上线需 Nginx 或后端配合；JSONP 已淘汰，仅限极老浏览器且服务端明确支持时谨慎使用。
用 fetch 发送基础 AJAX 请求最稳妥
现代浏览器中，fetch 是替代 XMLHttpRequest 的首选。它返回 Promise，写法简洁，但默认不带 cookie，且不会自动拒绝非 2xx 响应（比如 404、500 仍算成功）。
常见错误是忽略 response.ok 或没处理网络异常：
fetch('/api/data')
.then(response => {
if (!response.ok) {
throw new Error(`HTTP error: ${response.status}`);
}
return response.json();
})
.catch(err => console.error('请求失败:', err));
- 要发 cookie，必须显式加
credentials: 'include' - POST 请求需手动设
Content-Type请求头（如'application/json'） - 超时需自行封装：原生
fetch不支持 timeout 参数
跨域报错 Blocked by CORS policy 怎么定位
这个错误只在浏览器控制台出现，服务端完全感知不到——说明请求根本没发出去，被浏览器预检（preflight）拦截了。关键看两点：
- 是否带了自定义 header（如
Authorization）、非简单方法（如PUT）、非简单 content-type（如application/json）？这些会触发 OPTIONS 预检 - 响应头是否包含
Access-Control-Allow-Origin，且值匹配当前页面协议+域名+端口（不能是通配符*同时又带 credentials）
用 curl -I 或 Postman 直接访问接口，能绕过浏览器限制，确认服务端是否真返回了 CORS 头。
立即学习“Java免费学习笔记（深入）”；
后端没权限改配置？试试代理绕过跨域
开发阶段最常用的是 Webpack/Vite 的 devServer 代理，本质是把前端请求转给同源后端，再由后端转发到目标 API，浏览器全程只看到同源请求。
Vite 配置示例（vite.config.ts）：
export default defineConfig({
server: {
proxy: {
'/api': {
target: 'https://example.com',
changeOrigin: true,
rewrite: (path) => path.replace(/^\/api/, '')
}
}
}
})
-
changeOrigin: true是必须的，否则 Host 头还是前端地址 - 代理只在
vite dev有效，build 后失效，上线得靠 Nginx 或 CDN 配置 - 不要在代理路径里写死
https://——本地开发可能用 http，代理会失败
JSONP 已淘汰，别再用它“解决”跨域
JSONP 利用 标签不受同源策略限制的特性，但它只支持 GET，无法设 header、无错误捕获、无法取消请求，且服务端必须配合返回函数调用格式（如 callback({...})）。现代项目基本不用。
真正需要兼容老浏览器（IE10 以下）且无法改服务端时，才考虑 JSONP，但前提是对方明确支持。否则强行套用只会卡在回调不执行或 callback is not defined 错误里。
跨域的本质是浏览器策略，不是 JS 能绕开的。所有“前端解决跨域”的说法，其实都是换种方式让请求看起来同源，或者让服务端愿意接受它——后者才是正解，只是开发期常没权限改。
