同源策略是浏览器实施的安全机制，限制非同源脚本读取响应、访问DOM或存储数据；img/script/link等标签可跨域加载资源但不可读取响应，而fetch/AJAX因需JS处理响应体故受CORS严格约束。
HTML 标签本身不依赖、也不执行同源策略——浏览器才执行，而且只在特定场景下 enforce。
你写 <img src="https://cdn.example.com/photo.jpg" alt="HTML跨域依赖同源策略吗_HTML跨域提升同源策略方法【手册】" > 能加载成功，不是因为“HTML 支持跨域”，而是因为 <img alt="HTML跨域依赖同源策略吗_HTML跨域提升同源策略方法【手册】" > 标签的资源加载行为被浏览器明确豁免了同源检查。同理，<script></script>、<link rel="stylesheet"> 也属于这类“可跨域加载但不可读取响应”的标签。
真正受同源策略限制的，是 JavaScript 对响应内容的读取能力（比如 fetch() 返回的 response.text()）、对 DOM 的访问（如 iframe.contentDocument），以及对 Cookie / localStorage 的操作。
为什么 fetch 会报 CORS 错误，而 img 不会
核心区别在于：浏览器是否允许 JS 拿到响应体。
立即学习“前端免费学习笔记（深入）”；
-
<img alt="HTML跨域依赖同源策略吗_HTML跨域提升同源策略方法【手册】" >加载跨域图片 → 浏览器渲染它，但 JS 不能调用img.src读取二进制数据，也不能对这张图调用canvas.toDataURL()（会触发SecurityError） -
fetch('https://api.example.com/data')→ 浏览器不仅发请求，还试图把响应体交给 JS 处理，这就触发 CORS 检查
- 错误典型表现：
Failed to fetch: No 'Access-Control-Allow-Origin' header is present - 预检失败时控制台可能只显示
net::ERR_FAILED，必须打开 Network 面板，点开OPTIONS请求看响应头 - 带
Authorizationheader、自定义 header（如X-Trace-ID）或非简单 Content-Type（如application/json）都会强制触发预检
HTML 表单跨域提交能绕过同源策略吗
能发出去，但拿不到结果——这是关键分水岭。
-
<form action="https://other-domain.com/submit" method="POST"></form>可以成功提交，浏览器不拦 - 但提交后跳转到目标页面，或嵌入隐藏
iframe接收响应，JS 仍无法读取该 iframe 的contentDocument（除非双方都配合postMessage+origin校验）
- 适用场景：埋点上报、日志采集、无需反馈的表单（如订阅邮箱）
- 不适用场景：需要校验返回状态码、解析 JSON 响应、上传文件后展示上传结果
- 若需响应，必须走服务端代理，或让目标接口开启 CORS（前端改 HTML 或 JS 都无效）
CORS 配置中 Access-Control-Allow-Origin 不能填 *
填 * 看似方便，但和 credentials: 'include' 互斥——一旦前端 fetch 带了 cookie 或 authorization，服务端就必须指定具体源，不能用通配符。
- 错误配置示例：
Access-Control-Allow-Origin: *+Access-Control-Allow-Credentials: true→ 浏览器直接拒绝响应 - 正确做法：服务端动态读取请求头
Origin，白名单匹配后原样回写（如https://your-app.com），再加Access-Control-Allow-Credentials: true - Node.js Express 中常见疏漏：没在 OPTIONS 响应里重复设置这些 header，导致预检失败
实际开发中最容易被忽略的一点：跨域问题从来不是前端单方面能“提升”或“绕过”的。所有看似“前端解决”的方案（如代理、JSONP、postMessage），本质都是换了一种通信路径，而非解除浏览器的安全机制。真正决定能否跨域读取响应的，永远是服务端是否返回了合法、完整、上下文匹配的 CORS 响应头。
