crossorigin属性通过启用cors请求使浏览器能合法读取跨域图片像素数据，避免canvas被污染；需服务端配合返回正确access-control-allow-origin等响应头，且js动态创建图片时必须在设置src前赋值crossorigin。
crossorigin属性为什么能防止canvas污染
当用drawImage()把跨域图片画到<canvas></canvas>上，浏览器会立刻标记canvas“已污染”，后续调用toDataURL()或getImageData()就会报错：SecurityError: The canvas has been tainted by cross-origin data。根本原因不是图片加载失败，而是浏览器为安全默认拒绝读取跨域资源像素数据。加crossorigin属性，本质是让浏览器改用CORS方式发起图片请求——它会带上Origin头，要求服务端返回Access-Control-Allow-Origin响应头，从而获得读取权限。
crossorigin="anonymous"和crossorigin="use-credentials"的区别
这两个值决定CORS请求是否携带凭据（如Cookie、HTTP认证）：
-
crossorigin="anonymous"：发送不带凭据的CORS请求（即credentials: 'omit'），服务端只需返回Access-Control-Allow-Origin: *或明确匹配的源即可 -
crossorigin="use-credentials"：发送带凭据的CORS请求（credentials: 'include'），服务端必须返回Access-Control-Allow-Origin具体域名（不能是*），且必须包含Access-Control-Allow-Credentials: true
99%的静态图床场景用crossorigin="anonymous"就够了；如果图片接口依赖登录态Cookie，才考虑use-credentials，但要确保后端配置严格匹配。
只加crossorigin属性还不够：服务端必须配合
前端加了crossorigin，但服务端没返回正确CORS头，图片照样无法用于canvas读取——此时控制台会报CORS error，而不是canvas污染错误。常见漏配点：
- CDN或对象存储（如AWS S3、阿里OSS）默认不开启CORS，需手动配置规则，且
AllowedOrigins不能写*（当用了use-credentials时） - Nginx反向代理图片时，需显式透传CORS响应头，例如添加
add_header Access-Control-Allow-Origin "*"; - 本地开发用file://协议打开HTML，所有跨域请求都会失败（浏览器限制），必须用
http-server或VS Code Live Server启动本地服务
动态设置crossorigin容易被忽略的时机问题
如果图片是JS动态创建的（比如new Image()），必须在设置src之前就赋值crossOrigin属性，否则CORS请求不会生效：
const img = new Image(); img.crossOrigin = 'anonymous'; // ✅ 必须在src前设置 img.src = 'https://example.com/photo.jpg'; // ❌ 顺序颠倒会导致CORS失效
另外，修改已加载图片的crossOrigin属性无效，哪怕重新赋值src也不会触发新请求——必须新建Image实例。
真正麻烦的是第三方资源：你无法控制其服务端CORS策略，这时候要么换图源，要么用代理中转（但可能违反服务条款），或者放弃canvas像素操作，改用CSS滤镜等不触发污染的方式处理。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
