HTML 页面本身不处理跨域，真正起作用的是浏览器对 JavaScript 发起的请求（如 fetch、XMLHttpRequest）施加的同源策略限制；而 <form>、<script>、<img> 等标签天然不受限，因浏览器仅对脚本读取响应内容的行为做同源检查。
直接说结论：HTML 页面本身不处理跨域，真正起作用的是浏览器对 JavaScript 发起的请求（如 fetch、XMLHttpRequest）施加的同源策略限制；而原生 <form> 提交、<script>、<img> 等标签天然不受限——所以“HTML 如何解决跨域”本质是问「前端 JS 怎么安全发跨域请求」或「后端怎么配合放行」。
为什么 fetch / axios 会报跨域错误，但 form 提交却能发出去？
因为浏览器只对脚本发起的读取响应内容的行为做同源检查。表单提交是导航级行为，发出去没问题，但你拿不到响应体（response.text() 或 response.json() 会失败）。而 fetch 默认要读响应，就触发了 CORS 检查。
- 原生
<form action="https://api.other.com/submit" method="POST">可以成功发送，但 JS 无法用document.forms[0].submit()后再读返回值 -
fetch('https://api.other.com/data')会先发OPTIONS预检，若后端没返回Access-Control-Allow-Origin，直接卡在预检阶段，控制台 Network 面板里连主请求都看不到 -
<script src="https://cdn.example.com/lib.js"></script>不受限制，但加载失败时无法拿到 HTTP 状态码，只能靠onerror
后端配 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。
立即学习“前端免费学习笔记（深入）”；
- 必须手动注册
CorsConfigurationSourceBean，且路径要覆盖/**，不能只写/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 的联动关系。漏掉任意一环，前端就收不到数据，后端日志里还查不到错误——它根本没进来。
