HTML跨域不影响同源策略,因HTML本身不执行该策略;真正受约束的是JavaScript对响应的读取、DOM访问等操作,浏览器依据页面origin强制实施限制。
不能。HTML跨域本身不提升、不削弱、也不改变同源策略——它压根不是同源策略的参与者,只是被同源策略约束的对象之一。
所谓“HTML跨域”,常被误解为「把一个 HTML 文件放到另一个域名下就能绕过限制」。实际不是:浏览器判断同源,依据的是当前页面的 location.origin(协议+主机+端口),和这个 HTML 文件物理存放在哪台服务器上无关。你用 curl 下载一个来自 https://api.example.com/index.html 的 HTML 并双击本地打开,它的源是 file://,和任何 HTTP 网站都不同源;你把它部署到 http://test.com,那它的源就变成 http://test.com,和 https://test.com 依然跨域。
常见错误现象:
index.html,fetch('/api') 报 TypeError: Failed to fetch —— 不是后端没开 CORS,而是 file:// 源下所有网络请求默认被禁用(部分浏览器甚至不发出去)/var/www/html,但访问地址是 http://localhost:8080,而 API 在 http://localhost:3000 → 明明都是 localhost,但端口不同,直接触发同源策略拦截<img>、<script> 能跨域,是因为它们只做“嵌入”,不读响应体同源策略对三类跨源操作区别对待:
立即学习“前端免费学习笔记(深入)”;
<img src="https://cdn.example.com/logo.png">、<script src="https://cdn.jsdelivr.net/npm/vue@3"></script> —— 浏览器只管加载并渲染/执行,不让你用 JS 读取图片像素或脚本源码<a href="https://evil.com">、表单 action="https://third-party.com/submit" —— 你能发起请求,但收不到响应内容fetch('https://api.example.com/data')、XMLHttpRequest、iframe.contentWindow 访问不同源子页 DOM —— 这才是你日常遇到“跨域报错”的主因所以,别指望靠换几个 HTML 标签“提升”同源策略;能绕过的只是嵌入场景,而你要的 AJAX 数据交互,必须走合法路径。
当你看到 Access-Control-Allow-Origin: *,别理解成“服务器开了后门”。它其实是服务器在响应头里向浏览器申明:fetch() 这种读操作,我允许谁来调用。浏览器收到后,才决定是否把响应体暴露给前端 JS。
关键点:
<img> 加载不受影响,也不需要它Access-Control-Allow-Origin: * 不允许带凭据(如 Cookie),要带凭据必须写具体域名,且前端需设 credentials: 'include'
OPTIONS)只在非简单请求时触发,比如带自定义 header、Content-Type: application/json、method 是 PUT/DELETE
典型错误:后端加了 Access-Control-Allow-Origin: *,但前端 fetch(url, { credentials: 'include' }) 仍失败 → 原因就是 * 和凭据不兼容,必须改用具体域名。
真正容易被忽略的,是同源策略的“不可绕过性”:它由浏览器硬编码实现,不依赖 HTML 内容、不随 JS 执行而变化,也不受 document.domain 影响(该 API 仅对 iframe DOM 访问和 cookie 有效,对 fetch 完全无效)。想让它“松动”,唯一办法是让两端真正同源,或让服务端配合输出正确的 CORS 头——没有中间态。