html表单提交不受同源策略限制，但js读取响应受cors约束；跨域提交需服务端校验origin头，iframe跨域访问contentdocument会被阻止。
HTML 表单本身不参与同源策略校验
表单提交（form.submit() 或用户点击提交）不受浏览器同源策略限制——它会照常发出请求，哪怕目标是跨域地址。真正受阻的，是 JavaScript 读取响应内容（比如用 fetch 或 XMLHttpRequest），或者表单提交后试图用 JS 拦截、解析返回的 HTML/JSON。
常见错误现象：net::ERR_BLOCKED_BY_CLIENT 看起来像同源问题，其实是广告拦截器或隐私插件干的；而 No 'Access-Control-Allow-Origin' header 这类报错根本不会出现在纯表单提交里，只会在你用 JS 发起跨域请求时出现。
- 表单提交本质是浏览器发起的“导航级请求”，等价于用户手动在地址栏输入 URL 回车
- 如果你需要 JS 控制提交过程并读取响应，就必须走
fetch+ CORS，而不是依赖<form></form> - 服务端对表单提交的响应状态码（如
302跳转）、Content-Type（如text/html）会影响前端能否安全处理结果
想让表单“看起来”遵守同源，得靠服务端配合
浏览器不拦表单提交，但服务端可以拒收跨域来的 POST 请求。关键不是前端加什么属性，而是后端是否校验 Origin 或 Referer 头。
使用场景：你控制前后端，想防止其他网站用 <form action="your-api.com/login"></form> 恶意提交账号密码。
立即学习“前端免费学习笔记（深入）”；
- 检查请求头中的
Origin是否在白名单内（注意：Origin在重定向后可能丢失） -
Referer可被伪造，仅作辅助判断，不能替代Origin - 若拒绝，返回
403或400，不要返回302到登录页——那反而会让攻击者完成跳转
form 的 target 和 iframe 容易引发跨域读取失败
当用 <form target="myframe"></form> 提交到隐藏 <iframe></iframe>，再用 JS 读取 iframe.contentDocument 时，就会触发同源策略报错：Blocked a frame with origin "xxx" from accessing a cross-origin frame。
这是真·同源限制，且无法绕过。
- 只有
iframe和父页面同源，才能用 JS 访问其contentDocument或contentWindow - 如果必须异步提交又不想暴露 API 给 CORS，可用服务端代理中转：表单提交给同域接口，由它转发请求并返回结果
- 现代替代方案是改用
fetch+credentials: 'include'，配合服务端设置Access-Control-Allow-Credentials: true
rel="noopener" 和 form.action 的协议/域名一致性
虽然不直接关联同源策略，但 form.action 若写成相对路径（如 "/api/submit"）或协议相对路径（如 "//evil.com/hook"），可能意外导向跨域地址，导致后续 JS 处理失焦或 cookie 泄露。
容易踩的坑：开发环境用 http://localhost:3000，生产却漏掉 https:// 前缀，导致表单提交到 http://yoursite.com（被降级）甚至空协议下被劫持。
- 始终用完整 URL 或明确的相对路径（
/path开头，不带//） - 避免在
action中拼接用户可控数据（如action="/search?q="+input.value），以防 XSS 或开放重定向 - 检查构建工具是否把
process.env.API_BASE注入到了 HTML 模板里，而不是靠 JS 动态赋值form.action
crossorigin 属性或 referrerpolicy 就能控制表单行为——这些属性对 <form></form> 根本无效，只作用于 <script></script>、<img alt="HTML表单怎样设置同源策略_HTML表单设置同源策略流程【详解】" > 等资源加载。 
