crossorigin属性仅在需读取跨域资源原始内容时必需，如canvas操作、WebGL纹理绑定、AudioContext解码等；纯展示无需添加，且必须与服务端CORS响应头配合生效。
crossorigin 属性到底什么时候必须加
只有当你需要在 JavaScript 中读取媒体资源的原始内容时，crossorigin 才是必需的。比如：<img> 加载后调用 canvas.getContext('2d').drawImage() 再执行 toDataURL() 或 getImageData()；<video> 调用 captureStream() 或用 WebGL 纹理绑定；<audio> 传给 AudioContext.decodeAudioData() —— 这些操作都会触发“污染检查”，没配 crossorigin 就直接报错。
纯展示场景（如仅显示图片、播放视频、加载字体）不需要加，浏览器默认允许跨域嵌入，但禁止读取。
- 加了
crossorigin但服务端没返回Access-Control-Allow-Origin→ 请求失败，控制台报CORS error - 没加
crossorigin却尝试读取 canvas 数据 → 报Unable to get image data from canvas because the canvas has been tainted -
<link rel="stylesheet">加了crossorigin但服务端没配 CORS → 样式表被静默丢弃，页面无样式且无明显报错
anonymous 和 use-credentials 到底怎么选
crossorigin="anonymous" 是绝大多数场景的默认选择：它让浏览器发一个不带 cookie、HTTP 认证头的 CORS 请求，服务端只需返回 Access-Control-Allow-Origin: * 或指定域名即可响应。
crossorigin="use-credentials" 只在你明确需要携带用户登录态（比如 CDN 上的私有图片资源受 session 保护）时才用。此时服务端必须返回 Access-Control-Allow-Origin 的具体域名（不能是 *），且要带上 Access-Control-Allow-Credentials: true，否则浏览器直接拒绝响应。
立即学习“前端免费学习笔记（深入）”；
- 设成
use-credentials但服务端漏了Access-Control-Allow-Credentials: true→ 控制台提示Response to preflight request doesn't pass access control check - 设成
use-credentials但服务端Access-Control-Allow-Origin写了*→ 浏览器直接忽略响应，不执行后续逻辑 - 属性值写成
crossorigin="true"或空字符串 → 浏览器按anonymous处理，但语义不清，建议显式写明
script/link/img/video 都支持 crossorigin，但行为差异很大
不同标签启用 crossorigin 后影响的边界完全不同，不能一概而论：
-
<script crossorigin>：主要影响错误堆栈可见性。不加时，跨域脚本报错只显示Script error.；加了且服务端配好 CORS，window.onerror才能拿到完整message、filename、lineno -
<link crossorigin>：影响 CSSOM 访问权限。不加时，JS 无法读取document.styleSheets[0].cssRules；加了且服务端配好，才能动态插入/删除规则 -
<img crossorigin>：影响 canvas 污染状态。不加时，drawImage()后 canvas 不可读；加了且服务端配好，才能安全导出数据 -
<video crossorigin>：影响媒体元数据和帧捕获。不加时，video.videoWidth可读，但captureStream()或drawImage()到 canvas 会失败
注意：<iframe> 不支持 crossorigin 属性，它的跨域通信靠 postMessage 和响应头 X-Frame-Options / Content-Security-Policy: frame-ancestors 控制。
integrity 和 crossorigin 必须配合使用
只要用了 integrity（比如 CDN 引入 jQuery 时带 hash），就必须同时加 crossorigin，否则浏览器会直接拒绝加载该资源 —— 这不是 bug，是 SRI（子资源完整性）的强制安全要求。
原因在于：SRI 需要浏览器下载完整资源后计算哈希，而跨域资源若未启用 CORS，浏览器出于安全限制，不允许 JS 读取响应体（哪怕只是用来算 hash）。所以 integrity 实际上隐式开启了 CORS 检查。
- 只写
integrity不写crossorigin→ 控制台报Failed to find a valid digest in the 'integrity' attribute，资源加载失败 - 写了
crossorigin="anonymous"但服务端没返回Access-Control-Allow-Origin→ 请求被拦截，integrity根本没机会校验 - CDN 返回的资源响应头含
Access-Control-Allow-Origin: *，但没开缓存或 ETag 不稳定 → 可能导致重复下载、hash 校验失败（尤其压缩/非压缩版本混用时）
最易被忽略的一点：本地开发时用 file:// 协议打开 HTML，所有 crossorigin 请求都会失败 —— 因为 file:// 没有 origin，CORS 机制不适用，此时应改用本地服务器（如 python -m http.server）调试。
