file://协议下crossorigin属性完全被忽略，因该协议不触发CORS流程；需改用HTTP服务（如npx serve）并配置响应头才能生效。
file:// 协议下 crossorigin 属性完全被忽略
是的，所有主流浏览器（Chrome、Firefox、Safari、Edge）在 file:// 协议下都会直接忽略 crossorigin 属性。这不是 bug，而是规范行为——crossorigin 仅在涉及 HTTP/HTTPS 网络请求时才生效，而 file:// 不触发 CORS 流程，也不发送 CORS 请求头，更不会校验响应头。
为什么 crossorigin="anonymous" 在本地 HTML 里没用
常见误解是：加了 crossorigin 就能绕过 canvas 污染限制或读取图片尺寸。实际在 file:// 下：
-
<img src="data:image/png;base64,...>或同目录.png文件，即使加crossorigin="anonymous"，加载后仍无法用于canvas.drawImage()后调用canvas.toDataURL()—— 会报SecurityError: Failed to execute 'toDataURL' on 'HTMLCanvasElement': Tainted canvases may not be exported. - 浏览器根本不会为
file://资源发起带Origin: null的请求，也不会检查Access-Control-Allow-Origin响应头（因为压根没发请求） -
fetch()同样受限：fetch("image.png", { mode: "cors" })在file://下会直接 reject，错误信息类似Failed to fetch（无详细原因），且不进入 network 面板
真正可行的本地开发替代方案
想让 crossorigin 生效，必须脱离 file://：
- 用轻量 HTTP 服务启动本地目录，例如：
npx serve、python3 -m http.server 8000、npm install -g http-server && http-server - 确保图片资源通过 HTTP 提供（如
http://localhost:8000/photo.jpg），此时crossorigin="anonymous"才会触发 CORS 预检（若需要）并影响 canvas 污染状态 - 如果图片本身不带 CORS 响应头，可配合代理（如 vite 的
server.proxy）或后端加 header，否则仍会因缺少Access-Control-Allow-Origin被拒绝 - 开发阶段避免依赖
file://调试跨域相关逻辑，否则上线后行为会突变——本地看似“能跑”，实则掩盖了真实 CORS 配置缺失问题
容易被忽略的细节：data URL 和 blob URL 也不受 crossorigin 影响
crossorigin 只对 HTTP(S) URL 生效。以下情况均无视该属性：
-
<img src="data:image/svg+xml;base64,..." crossorigin="anonymous">→ 属性被忽略，canvas 使用后必然污染 -
URL.createObjectURL(blob)生成的blob:URL → 无 origin 概念，crossorigin无效 - 通过
iframe加载同目录 HTML → 即使加crossorigin，也无法跨 frame 访问内容（same-origin policy 仍基于file://的 origin 判定）
真正要解决 canvas 污染或跨域资源读取，核心不是加属性，而是让资源走 HTTP 并配好 CORS 响应头——file:// 下没有妥协路径。
