crossorigin="use-credentials"不会触发预检请求，因img加载属简单请求；但服务端必须返回精确匹配的access-control-allow-origin和access-control-allow-credentials:true，否则浏览器直接拒绝响应。
crossorigin="use-credentials" 会触发预检请求吗？
不会。只要 img 标签设置了 crossorigin="use-credentials"，浏览器就**直接发送带 Cookie 和 Authorization 头的请求**，不走 OPTIONS 预检——因为 img 的跨域资源加载属于“简单请求”范畴，即使带凭证也不触发预检。
但前提是服务端必须明确返回响应头：Access-Control-Allow-Origin 不能是通配符 *，必须精确匹配请求源（比如 https://a.com），且要带上 Access-Control-Allow-Credentials: true，否则浏览器直接拒绝解析响应。
为什么图片加载后 canvas 仍报 “Tainted canvas” 错误？
这是最常见的坑：即使 img 成功加载了跨域图片，只要没通过 CORS 验证（即响应中缺失 Access-Control-Allow-Origin 或值为 *），后续调用 canvas.getContext('2d').drawImage() 就会污染 canvas，导致读取像素（getImageData）或导出数据（toDataURL）失败。
-
crossorigin属性必须和服务器响应头严格配合，缺一不可 - 如果服务端只返回
Access-Control-Allow-Origin: *，哪怕加了crossorigin="use-credentials"也无效——因为带凭证时不允许用通配符 - 开发时可用
curl -I检查实际响应头，注意确认是否含Access-Control-Allow-Credentials: true
fetch 与 img 在 use-credentials 行为上有何关键差异？
fetch 默认不发凭证，需显式设 credentials: 'include'；而 img 只要设 crossorigin="use-credentials" 就自动携带凭证（Cookie + Authorization），无需额外配置。
但两者对服务端的要求一致：都要求 Access-Control-Allow-Origin 精确匹配 + Access-Control-Allow-Credentials: true。区别在于，fetch 可以在请求前做逻辑判断、重试或降级，img 是声明式加载，失败只能监听 onerror，无法拦截或修改请求头。
- 若后端只支持
Origin白名单校验（如 Nginx 用map动态设置Access-Control-Allow-Origin），务必确保包含当前页面域名 -
crossorigin="anonymous"不发凭证，此时服务端可返回Access-Control-Allow-Origin: *，但无法读取受保护资源（如需登录态的图片）
CDN 或图床不支持 credentials 时怎么办？
很多公共图床（如 GitHub raw、Cloudinary 免费 tier）默认不返回 Access-Control-Allow-Credentials: true，甚至不支持自定义响应头，此时硬加 crossorigin="use-credentials" 只会让请求失败或降级为匿名模式（取决于浏览器行为）。
可行路径只有两条：
- 换用支持完整 CORS 配置的托管服务（如自建 Nginx、S3 + CloudFront 自定义响应头、或付费版 CDN）
- 服务端代理：前端请求自己后端接口，由后端 fetch 图片并透传响应头（注意处理缓存、MIME 类型和大文件流）
- 避免依赖 canvas 读取——比如用纯 CSS 裁剪、
background-image替代drawImage，绕过污染限制
真正容易被忽略的是：本地开发时 localhost 和线上域名不同，会导致 Origin 不一致，从而让原本在线上能工作的 CORS 配置在本地失效——别只测线上环境。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
