crossorigin属性不是CORS配置开关，仅声明资源以CORS模式加载，必须与服务端返回的Access-Control-Allow-Origin等响应头严格配对才生效；单独添加无效。
HTML 本身不配 CORS，crossorigin 属性不是“配置 CORS”，它只是告诉浏览器：这次资源加载要走 CORS 流程——前提是服务端愿意配合并返回正确的响应头。
为什么 crossorigin 加了也不起作用
加了 crossorigin="anonymous" 却仍被拦截或无法读取内容，大概率是服务端没返回 Access-Control-Allow-Origin。浏览器看到这个属性，就会在请求头里带上 Origin，然后严格比对服务端响应头里的 Access-Control-Allow-Origin 值：
- 如果服务端返回
Access-Control-Allow-Origin: *→ 图片/脚本能加载，JS 也能读响应（但拿不到 cookie） - 如果前端用了
crossorigin="use-credentials"，而服务端没返回Access-Control-Allow-Credentials: true→ 请求直接失败，连预检都过不去 - 如果服务端返回了
Access-Control-Allow-Origin: https://myapp.com，但前端页面实际跑在http://localhost:3000→ 不匹配，被拒绝
crossorigin 在哪些 HTML 标签上有效
只对部分资源加载行为生效，且效果各不相同：
-
<img>：加crossorigin才能用 JS 读像素（比如canvas.drawImage()后调ctx.getImageData()），否则报 “Tainted canvas” -
<script>：加了才能捕获运行时错误的完整堆栈（否则只有 “Script error.”），也支持integrity校验 -
<link rel="stylesheet">：加了才允许 JS 读取 CSSOM（如document.styleSheets[0].cssRules），否则抛 SecurityError -
<video>、<audio>：加了才能读取videoWidth/videoHeight或调用captureStream() -
<iframe>、<object>、<embed>：不支持crossorigin，它们走的是postMessage或frame-ancestors控制逻辑
常见误用：crossorigin 和 meta 标签混用
有人在 <head> 里写：<meta http-equiv="Access-Control-Allow-Origin" content="*"> —— 这完全无效。原因很直接：
立即学习“前端免费学习笔记（深入）”；
-
Access-Control-Allow-Origin是响应头，只能由服务器在 HTTP 响应中返回 -
meta http-equiv只能模拟极少数可被 HTML 解析的响应头（如Content-Type、Refresh），CORS 相关头不在支持列表里 - 哪怕你本地用
file://打开 HTML，或者用 Live Server 启动，只要没后端返回对应头，crossorigin就形同虚设
真正该检查的服务端响应头组合
前端加了 crossorigin，服务端必须按需返回一组匹配的头。最容易翻车的是这几个组合：
- 前端用
crossorigin="use-credentials"→ 服务端必须同时返回：Access-Control-Allow-Origin: https://yourdomain.com（不能是*） +Access-Control-Allow-Credentials: true - 前端发了自定义 header，比如
Authorization: Bearer xxx→ 服务端必须返回：Access-Control-Allow-Headers: Authorization，且预检（OPTIONS）响应里也要有 - 用
<img crossorigin="anonymous">加载 OSS 图片 → 要去 OSS 控制台配 CORS 规则，填对“允许来源”“允许方法（GET）”“允许头（空或 *）”，不是改 HTML 能解决的
最常被忽略的一点：DCDN、CDN 缓存可能覆盖源站响应头。即使后端代码写了正确头，如果 CDN 没透传或自己加了冲突头（比如删了 Access-Control-Allow-Origin），前端照样收不到。
