HTML跨域请求怎么解决？CORS问题全攻略

本文深入解析了HTML跨域请求中CORS（跨域资源共享）问题的本质与完整解决方案，明确指出浏览器拦截的根本原因在于服务端缺失关键响应头（如Access-Control-Allow-Origin），而非前端代码错误；文章系统梳理了前后端协同配置要点：前端需正确设置fetch的mode和credentials，避免误用no-cors，开发期可借助Vite代理实现“伪同源”请求（注意changeOrigin等关键配置），而线上环境必须依赖后端精准返回全套CORS头（包括Origin、Credentials、Methods、Headers等），尤其强调credentials: 'include'时Origin不可为*，并提供Express示例与调试建议——真正掌握CORS，关键在于理解浏览器与服务端之间的协议契约，而非堆砌前端技巧。

为什么 fetch 会报 “No 'Access-Control-Allow-Origin' header” 错误

这是浏览器主动拦截的，不是你的代码写错了，也不是后端挂了——而是服务端响应里没带 Access-Control-Allow-Origin 这个响应头。浏览器看到请求是跨域（协议、域名、端口任一不同），且响应头缺失该字段，就直接拒绝把响应体交给 JS。你看到的错误只是结果，真正的问题在服务端配置或代理环节。

前端用 fetch 发起跨域请求时必须加 mode: 'cors'

很多人以为只要写了 fetch('https://api.example.com/data') 就行，其实默认 mode 是 'cors'，但一旦你手动加了 credentials: 'include' 却没配 mode，或者用了 mode: 'no-cors'，就会导致：要么被静默降级成 opaque 响应（JS 拿不到任何数据），要么直接报错。正确做法是明确声明：

fetch('https://api.example.com/data', {
  method: 'GET',
  mode: 'cors',           // 必须显式写，尤其配合 credentials 时
  credentials: 'include'  // 如需带 cookie，后端也得允许 origin 且不能用 *
})

• credentials: 'include' 时，后端 Access-Control-Allow-Origin 不能为 *，必须是具体域名
• 开发时若后端未配 CORS，临时用 mode: 'no-cors' 是无效的——它只允许发出请求，但 JS 完全读不到响应
• Vite/webpack dev server 的 proxy 是前端开发期绕过 CORS 的常用方式，但它不改变线上行为

本地开发时用 Vite 的 server.proxy 绕过浏览器同源限制

这不是解决 CORS，而是让请求不跨域：把前端请求发给本地开发服务器（如 http://localhost:5173/api/），它再以服务端身份去调真实 API，这样浏览器眼里全是同源请求。Vite 配置示例如下：

export default defineConfig({
  server: {
    proxy: {
      '/api': {
        target: 'https://prod-api.example.com',
        changeOrigin: true,
        rewrite: (path) => path.replace(/^\/api/, '')
      }
    }
  }
})

• changeOrigin: true 是关键，它修改请求头中的 Host，避免目标服务因 Host 不匹配而拒收
• 这个 proxy 只在 vite dev 时生效，build 后的静态文件仍需后端配 CORS 或走 nginx 反向代理
• 不要在 proxy 里尝试加 headers 去伪造 CORS 响应头——浏览器根本不看代理层返回的头，它只看最终上游服务的响应

后端必须设置的最小 CORS 响应头组合

光有 Access-Control-Allow-Origin 不够。常见漏配导致 403 或预检失败：

• 简单请求（如 GET + JSON）至少需要：Access-Control-Allow-Origin + （可选）Access-Control-Allow-Credentials
• 非简单请求（如 POST + Content-Type: application/json、带自定义 header）会触发 preflight（OPTIONS 请求），此时还需：Access-Control-Allow-Methods、Access-Control-Allow-Headers、Access-Control-Allow-Origin
• Access-Control-Max-Age 可减少重复 preflight，建议设为 86400（24 小时）
• 如果前端用了 credentials: 'include'，后端必须同时设 Access-Control-Allow-Credentials: true，且 Access-Control-Allow-Origin 不能是 *

Node.js + Express 示例（注意顺序和条件）：

app.use((req, res, next) => {
  res.header('Access-Control-Allow-Origin', 'https://your-frontend.com');
  res.header('Access-Control-Allow-Credentials', 'true');
  res.header('Access-Control-Allow-Methods', 'GET,PUT,POST,DELETE,OPTIONS');
  res.header('Access-Control-Allow-Headers', 'Content-Type, Authorization');
if (req.method === 'OPTIONS') {
res.sendStatus(200);
} else {
next();
}
});

CORS 的核心约束不在前端代码里，而在浏览器与服务端的契约中；漏掉任意一个响应头，或前后端 credentials 设置不一致，都会让看似正常的请求突然失败。调试时优先检查 Network 面板里响应头是否齐全，而不是反复改 fetch 参数。

到这里，我们也就讲完了《HTML跨域请求怎么解决？CORS问题全攻略》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！