HTML跨域问题解决方案及接口处理方法

后端配 CORS 时最容易漏掉的三个头

CORS 不是加一个 Access-Control-Allow-Origin: * 就完事。尤其当你要传 Cookie 或读自定义响应头时，缺一不可：

• Access-Control-Allow-Origin：不能和 Access-Control-Allow-Credentials: true 共存于 *，必须写具体域名，比如 http://localhost:3000
• Access-Control-Allow-Credentials: true：前端 fetch 必须配 credentials: 'include'，否则浏览器直接拒绝发送 Cookie
• Access-Control-Expose-Headers：默认只暴露 Cache-Control、Content-Language 等基础字段；如果后端返回了 X-Request-ID 或 X-Total-Count，必须显式列出，前端才能用 response.headers.get('X-Request-ID') 读到

Spring Boot 2.4+ 的 @CrossOrigin 失效怎么办？

新版本把预检请求（OPTIONS）拦截得更严，@CrossOrigin 注解只管匹配到的接口路径，不管全局预检。常见表现是：GET/POST 正常，但带自定义 header 的请求直接 405 Method Not Allowed。

• 必须手动注册 CorsConfigurationSource Bean，且路径要覆盖 /**，不能只写 /api/**
• 如果用了 Spring Security，光配 CORS 不够，还得在安全配置里显式调用 http.cors()，否则预检请求被安全链提前拦掉
• Nginx 层加头时，注意预检请求可能不带 Origin 头，要用 if ($http_origin) { add_header ... } 包一层，避免给非跨域请求也加头引发问题

前端临时绕过（仅开发用）的两个现实办法

生产环境永远不要用，但本地调试时能省下大量后端改配置时间：

• Chrome 启动时加参数：--disable-web-security --user-data-dir=/tmp/chrome-dev（注意：必须关掉所有 Chrome 实例，且该模式下任何网页都能读你其他 Tab 的 Cookie，极度不安全）
• Vite / Webpack Dev Server 配代理：在 vite.config.ts 里写 server.proxy，把 /api/ 开头的请求转给后端，让前端“以为”是同源——这是最常用、最安全的开发方案

真正难的不是加几个响应头，而是理解哪些请求会触发预检、哪些不会，以及 credential 和 expose headers 的联动关系。漏掉任意一环，前端就收不到数据，后端日志里还查不到错误——它根本没进来。

今天关于《HTML跨域问题解决方案及接口处理方法》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！