浏览器在发请求前就因CORS拦截——同源策略检查失败，协议/域名/端口任一不同且响应头缺Access-Control-Allow-Origin时，请求根本不会到达服务端。
为什么 fetch 或 XMLHttpRequest 会直接被浏览器拦住？
不是后端没响应，是浏览器在发请求前就卡死了——CORS 是浏览器的同源策略检查环节，和服务器是否运行、接口是否通完全无关。只要协议、域名、端口任一不同，且响应头里没有合法的 Access-Control-Allow-Origin，请求根本不会发到服务端。
常见错误现象：Failed to fetch、No 'Access-Control-Allow-Origin' header is present、控制台报 CORS error 但 Network 面板里看不到该请求（状态栏显示 “(canceled)”）。
- 开发时用
file://协议打开 HTML 文件，也会触发 CORS（无 origin，浏览器视为不安全上下文） - 前端代理（如 Webpack DevServer 的
proxy）只对开发环境生效，打包后失效，别误以为“本地能跑线上就没事” -
credentials: true时，Access-Control-Allow-Origin不能为*，必须写明确域名，否则浏览器直接拒绝
后端加响应头是最直接有效的解法
前端改不了 CORS 策略，这是浏览器强制行为；真正可控的是服务端返回的响应头。只要后端在响应中带上正确的 CORS 头，浏览器就会放行。
关键响应头示例（以 Express 为例）：
立即学习“前端免费学习笔记（深入）”；
res.header('Access-Control-Allow-Origin', 'https://your-frontend.com');
res.header('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS');
res.header('Access-Control-Allow-Headers', 'Content-Type, Authorization');
res.header('Access-Control-Allow-Credentials', 'true'); // 如需带 cookie
-
Access-Control-Allow-Origin必须与前端发起请求的Origin完全匹配（协议+域名+端口），开发环境可动态读取请求头中的Origin做白名单校验，但生产环境建议硬编码或严格列表 - 预检请求（OPTIONS）必须返回 204 或 200，且不能带 body；很多后端框架默认不处理 OPTIONS，需显式配置路由或中间件
- Spring Boot 用户注意：
@CrossOrigin注解默认不支持credentials，需手动加allowCredentials = "true"并配origins，不能用"*"
开发阶段用代理绕过浏览器 CORS 检查
Webpack/Vite/Next.js 等工具的 dev server 代理，本质是让浏览器以为请求发给了同源地址，实际由本地服务转发——它不解决 CORS，而是让 CORS 根本不触发。
Vite 示例（vite.config.ts）：
export default defineConfig({
server: {
proxy: {
'/api': {
target: 'http://localhost:3000',
changeOrigin: true,
rewrite: (path) => path.replace(/^\/api/, '')
}
}
}
})
- 代理只在
vite dev下工作，构建产物（vite build）部署后无效，上线必须靠后端配 CORS -
changeOrigin: true是必需的，否则目标服务收到的Host头还是前端地址，可能被拒绝 - 不要代理到
https://xxx.com再跨域——这等于用一层代理制造新跨域，毫无意义
哪些“捷径”其实走不通
有人试过禁用浏览器安全策略（如 Chrome 启动加 --disable-web-security）、用 JSONP、甚至把前端代码塞进后端模板里渲染——这些要么仅限单机调试，要么已淘汰，要么违背架构原则。
- JSONP 只支持 GET，不支持
Authorization、cookie、自定义 header，现代 API 基本不用 - Chrome 无头模式或禁用安全策略：无法模拟真实用户环境，CI/CD 和协作开发完全不可用
- 前端拼接后端 HTML 模板：前后端耦合度飙升，SSR/CSR 混乱，后续维护成本远高于配好 CORS
CORS 的设计初衷就是让服务端声明“谁可以调我”，这个权力不在前端手里。绕开它容易，但真正在意交付质量、团队协作和长期维护的人，都会选择和后端对齐响应头规则——哪怕多一次沟通，也比埋个上线必炸的坑强。
