原生表单提交可跨域因属导航行为，绕过同源策略，但页面会跳转且无法获取响应；若需不跳转、解析JSON，应改用fetch+FormData并配置CORS与credentials；开发环境端口不同属跨域，优先使用代理而非CORS。
原生 <form> 提交本身不会被浏览器拦截跨域请求——它压根不走 CORS 流程，所以“处理跨域问题”这个说法本身就容易误导。真正要解决的，是「提交后拿不到响应数据」或「想留在当前页交互」时遇到的限制。
为什么表单提交能跨域但 JS 拿不到响应
浏览器把 <form> 提交当作导航行为（类似点击链接），不是脚本发起的资源读取操作，因此绕过同源策略检查。但这也意味着：
- 页面会跳转到目标域名，当前页 JS 执行环境立即销毁
- 即使服务端返回 JSON，浏览器也只会把它当纯文本显示，无法用
response.json()解析 - 如果你在控制台看到
CORS header 'Access-Control-Allow-Origin' missing，那说明你实际用的是fetch或XMLHttpRequest，不是原生表单
想不跳转、带 loading、解析 JSON？必须换 fetch + FormData
这是最常见也最合理的现代做法，但要注意几个硬性条件：
- 后端必须返回
Access-Control-Allow-Origin头（不能是*如果前端带 Cookie） - 前端
fetch要显式加credentials: 'include'才能传 Cookie，此时后端Access-Control-Allow-Origin必须写具体域名，不能用* - 含文件上传时，别手动设
Content-Type；用new FormData(form)让浏览器自动生成multipart/form-databoundary，否则触发预检失败 - 如果后端需要读取自定义请求头（如
X-Request-ID），得在响应中加Access-Control-Expose-Headers
用 target + iframe “伪同步”接收响应的实操要点
这方案只适合无法改后端、又必须不跳转的老系统，但坑多：
立即学习“前端免费学习笔记（深入）”；
-
<form target="my-frame">必须配一个同源的<iframe name="my-frame">（注意 name 和 target 值一致） - 服务端响应必须是 HTML 页面，且内嵌可执行脚本，例如：
<script>window.opener?.postMessage({success:true}, 'https://your-domain.com')</script></li> <li>父页面需监听 <code>window.addEventListener('message', ...)，并校验event.origin防止恶意调用 - 一旦服务端 302 重定向到跨域地址，
iframe就会因同源策略报错，无法继续通信
最容易被忽略的一点：表单是否真的需要“跨域”？很多场景其实是开发环境本地起服务（http://localhost:3000）调用后端 API（http://localhost:8080），协议+域名相同但端口不同也算跨域——这种情况下，优先考虑开发代理（如 Vite 的 server.proxy 或 Webpack DevServer 的 proxy），而不是硬上 CORS 或 iframe。
