加了crossorigin仍报CORS错误，根本原因是服务端未返回匹配的Access-Control-Allow-Origin响应头；crossorigin仅声明CORS模式，不解决跨域，必须前后端配置严格配对。
为什么 crossorigin 属性加了却还是报 CORS 错误
加了 crossorigin 却仍被浏览器拦截，大概率是因为属性值和实际请求头不匹配。浏览器只在两种情况下真正发起 CORS 请求：一是资源本身带 crossorigin 属性，二是 JS 主动用 fetch() 或 XMLHttpRequest 发起跨域请求。但光加属性没用——服务端必须返回合法的 Access-Control-Allow-Origin 响应头，且该头不能是 *（当请求带凭证时）。
常见错误现象：Failed to load resource: Origin ... is not allowed by Access-Control-Allow-Origin，或控制台提示 “CORS request did not succeed”。
-
crossorigin="anonymous"表示不携带 cookie、HTTP 认证等凭证，此时服务端可返回Access-Control-Allow-Origin: * -
crossorigin="use-credentials"表示携带凭证，此时服务端必须明确指定源（如Access-Control-Allow-Origin: https://example.com），且必须同时返回Access-Control-Allow-Credentials: true - 省略
crossorigin属性时，浏览器按“同源策略”处理，不会发预检请求，但跨域加载会失败（比如图片加载后无法读取canvas数据）
<img alt="html实现crossorigin属性配置_html crossorigin anonymous credentials【小技巧】" > 和 <script></script> 的 crossorigin 行为差异
同是加 crossorigin，不同标签触发的底层逻辑不同。对 <img alt="html实现crossorigin属性配置_html crossorigin anonymous credentials【小技巧】" > 来说，只有当你后续要用 JS 读取其像素数据（例如 ctx.drawImage(img, ...) 后调用 ctx.getImageData()）时，才需要它；否则加了也无感。而 <script></script> 加 crossorigin 则直接影响错误捕获——不加时，跨域脚本出错只会抛出泛化的 Script error.，加了才能拿到真实堆栈。
-
<img crossorigin="anonymous" src="https://cdn.example.com/photo.jpg" alt="html实现crossorigin属性配置_html crossorigin anonymous credentials【小技巧】" >：允许后续在<canvas></canvas>中使用该图，否则会触发SecurityError: Failed to execute 'getImageData' on 'CanvasRenderingContext2D' -
<script crossorigin="anonymous" src="https://cdn.example.com/app.js"></script>：使window.onerror或addEventListener('error')能捕获具体错误位置 -
<script crossorigin="use-credentials" src="https://api.example.com/bundle.js"></script>：仅在脚本需访问带 session cookie 的接口时才需要，但极少这么用（通常脚本本身不依赖 cookie）
fetch() 与 crossorigin 属性的关系
很多人以为 crossorigin 是给 fetch() 用的，其实不是。fetch() 的跨域行为由其 credentials 选项控制，和 HTML 标签上的 crossorigin 无关。HTML 的 crossorigin 只影响浏览器如何加载该资源（是否走 CORS 流程），不改变 JS 的请求逻辑。
立即学习“前端免费学习笔记（深入）”；
-
fetch('https://api.example.com/data', { credentials: 'omit' })≈crossorigin="anonymous"（不带凭证） -
fetch('https://api.example.com/data', { credentials: 'include' })≈crossorigin="use-credentials"（带 cookie） - HTML 中写
<script crossorigin src="..."></script>对fetch()调用毫无影响，反之亦然 - 混淆点：Chrome 控制台 Network 面板里，带
crossorigin的资源请求会显示cors类型，而fetch()请求显示cors或no-cors，取决于你传的mode选项
本地开发时 crossorigin 导致的 401/403 问题
本地用 file:// 协议打开 HTML 时，所有带 crossorigin 的资源请求都会失败，因为浏览器将 Origin: null 发给服务端，而绝大多数 CDN 或后端不会允许 null 源。这不是配置错误，而是协议限制。
- 现象：控制台报
Origin null is not allowed by Access-Control-Allow-Origin，状态码可能是 401 或 403 - 解决方式：不要用
file://直接双击打开，改用python3 -m http.server、npx serve或 VS Code Live Server 插件启动本地 HTTP 服务 - 临时绕过（仅调试）：Chrome 启动时加
--unsafely-treat-insecure-origin-as-secure="http://localhost:8080" --user-data-dir=/tmp/chrome-test，但不推荐长期依赖 - 注意：Webpack/Vite 开发服务器默认已设置
Access-Control-Allow-Origin: *，但生产构建后的静态资源仍需 CDN 或 Nginx 配置响应头
crossorigin 值严格对应，且 Access-Control-Allow-Credentials: true 和 Access-Control-Allow-Origin: * 不能共存——这点连不少 CDN 控制台都默认配错。 
