HTML本身不参与CORS控制，Access-Control-Allow-Origin必须由服务端在HTTP响应头中真实返回；meta标签无效，因浏览器只校验响应头且http-equiv不支持Access-Control-*字段。
HTML 文档结构本身不参与 CORS 控制，也不存在“HTML 配置跨域”的操作空间。所有浏览器对跨域资源的拦截，都发生在 HTTP 请求/响应层级，和 、 或任何 HTML 标签的嵌套结构无关。
为什么在 <meta> 里写 Access-Control-Allow-Origin 没用
很多人试过加这行：
<meta http-equiv="Access-Control-Allow-Origin" content="*">
它完全不生效。因为浏览器只检查服务器返回的 HTTP 响应头，比如 Access-Control-Allow-Origin、Access-Control-Allow-Methods，而 <meta http-equiv> 只能模拟少数几个可被 HTML 解析的响应头（如 Content-Type 或 Refresh），CORS 相关头不在支持列表里。
- 即使你把整个页面塞进 iframe，父页也无法靠改子页 HTML 来绕过同源策略
- 服务端没返回对应响应头，前端无论怎么调整 HTML 结构、加多少
<script></script>或<link>，都不会影响 CORS 校验结果 - OSS、DCDN、Nginx 等中间层配 CORS，也必须作用于响应头，不是改 HTML 文件内容
<img alt="HTML文档结构跨域资源共享与网页底层安全拦截策略设计" >、<script></script>、<link> 加 crossorigin 属性到底干啥
这些标签默认跨域加载不触发 CORS 校验，但加了 crossorigin 就会——它只是告诉浏览器：“请带上 Origin 头，并要求服务端返回 Access-Control-Allow-Origin”。这不是授权，而是“发起校验请求”。
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
立即学习“前端免费学习笔记（深入）”；
-
crossorigin="anonymous"：发请求时带Origin头，但不带 cookie；服务端需返回Access-Control-Allow-Origin: *或具体域名 -
crossorigin="use-credentials"：带 cookie 和认证信息；服务端必须返回Access-Control-Allow-Credentials: true，且Access-Control-Allow-Origin不能是*，必须精确匹配 - 没加
crossorigin的<img src="https://xxx.jpg" alt="HTML文档结构跨域资源共享与网页底层安全拦截策略设计" >能显示，但 JS 读像素会报Tainted canvas；加了但服务端没回对应头，图片照样显示，JS 还是读不了
哪些操作真正触发浏览器底层安全拦截
只有脚本主动发起、且试图读取响应体的请求，才会走完整 CORS 流程（含 OPTIONS 预检）。HTML 标签加载本身不触发，除非显式加 crossorigin。
-
fetch('https://api.example.com/data')→ 一定触发，控制台报错如Blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present -
XMLHttpRequest跨域请求 → 同样触发，错误信息类似，但不会出现在 Network 面板响应体里，而是 JS 执行流直接中断 -
new Image().src = 'https://xxx.jpg'→ 不触发；但ctx.drawImage(img, 0, 0)后调ctx.getImageData()→ 触发，因涉及像素读取 -
<iframe src="https://other.com/page.html"></iframe>→ 不触发 CORS，但 JS 访问其window或 DOM 会受 Same-Origin Policy 拦截，和 CORS 是两套机制
前端无法绕过 CORS 的根本原因
纯前端（不改服务端、不加代理、不换部署方式）条件下，没有合法手段让浏览器放行本该被拦的跨域响应读取。所谓“JSONP”“document.domain”“postMessage”都不是 CORS 替代方案，它们解决的是不同问题：
- JSONP 只支持 GET，且依赖服务端配合返回可执行脚本，和 CORS 机制无关
-
document.domain仅适用于同主域不同子域（如 a.example.com ↔ b.example.com），且现代浏览器已限制使用 -
postMessage是跨 iframe 通信协议，不解决 fetch 被拦的问题 - 本地开 server 或用 vite/webpack devServer 的 proxy，本质是把请求转成同源，绕开了浏览器 CORS 检查，但上线后仍需服务端配 CORS
最容易被忽略的点是：预检请求（OPTIONS）失败往往比主请求更隐蔽——它可能被 Nginx 405、Spring Boot 默认不处理 OPTIONS、OSS 规则未包含 OPTIONS 方法等导致静默 404，而你只盯着主请求的响应头看。
