crossorigin属性不是跨域开关，仅在、、、、标签上生效，必须与服务端Access-Control-Allow-Origin等响应头配合才有效；其他标签加了无效。
HTML 文档本身不控制 CORS，crossorigin 属性只是告诉浏览器“这次加载请走 CORS 流程”，但它不能绕过服务器响应头的校验，也不等于“开启跨域”。加了没用，大概率是因为服务端没返回 Access-Control-Allow-Origin。
哪些 HTML 标签支持 crossorigin 属性
只有少数资源加载标签能用这个属性，且语义明确：它只影响该资源的加载行为，不改变其他请求（比如 fetch()）的规则。
-
<img alt="HTML文档结构中的跨域资源共享属性" >、<script></script>、<link rel="stylesheet">、<video></video>、<audio></audio>支持crossorigin -
<iframe></iframe>、<form></form>、<a></a>不支持 —— 它们走的是其他机制（如postMessage或同源策略直接限制） -
<script></script>加了crossorigin后，若服务端未返回对应头，JS 错误堆栈会变成"Script error."，无法捕获具体行号
crossorigin="anonymous" 和 crossorigin="use-credentials" 的区别
这两个值决定浏览器是否在请求头中带上凭据（如 Cookie），并直接影响服务端必须返回的响应头。
-
crossorigin="anonymous"：发请求时带Origin头，但不带 Cookie；服务端只需返回Access-Control-Allow-Origin: *或精确匹配源即可 -
crossorigin="use-credentials"：发请求时带Origin+ Cookie；服务端必须返回Access-Control-Allow-Origin: https://your-site.com（不能是*）且Access-Control-Allow-Credentials: true - 如果用了
use-credentials但服务端漏了Access-Control-Allow-Credentials: true，浏览器直接拒绝响应，连状态码都看不到
为什么 <meta http-equiv="Access-Control-Allow-Origin"> 完全无效
浏览器只检查 HTTP 响应头，不解析 HTML 中的 <meta> 标签。这类写法常见于调试时的“病急乱投医”，但没有任何实际作用。
立即学习“前端免费学习笔记（深入）”；
-
Access-Control-Allow-Origin等响应头必须由服务端在 HTTP 响应中写出，比如 Nginx 的add_header、Express 的res.header()、OSS 控制台的 CORS 规则 - 即使你用本地服务器起一个
file://页面，再加 meta 标签，CORS 校验也不会触发 —— 因为没有 Origin 头，根本不算跨域请求 - 开发时用
http-server或live-server而不是双击打开 HTML，才能模拟真实跨域环境
Canvas 图像污染问题与 crossorigin 的真实关系
当你把跨域图片画到 <canvas></canvas> 上后调用 ctx.getImageData() 报错 “Tainted canvas”，根源不在 canvas，而在图片加载时没走 CORS 流程。
- 仅加
<img crossorigin="anonymous" alt="HTML文档结构中的跨域资源共享属性" >不够 —— 服务端必须返回Access-Control-Allow-Origin，否则浏览器仍视为“污染” - 如果图片来自 CDN（如阿里云 OSS），得去 OSS 控制台配 CORS 规则，而不是改前端代码
- 某些 CDN（如 DCDN）会覆盖源站的 CORS 响应头，此时需在 DCDN 侧单独配置出站响应头
真正容易被忽略的点是：同一个资源（比如一张图）可能被多次加载 —— 一次用于 <img src alt="HTML文档结构中的跨域资源共享属性" > 显示，另一次用于 new Image().src 再画到 canvas。前者没加 crossorigin，后者加了，但浏览器可能复用缓存，导致第二次请求没发 Origin 头，结果还是污染。解决办法是确保所有加载路径都显式声明 crossorigin，或强制加时间戳破缓存。
