HTML本身不能实现CORS配置，<meta http-equiv>对Access-Control-Allow-Origin完全无效，因其仅支持Content-Type等少数响应头，而CORS头必须由服务端在HTTP响应中真实返回；crossorigin属性仅声明加载模式，是否生效取决于服务端是否返回匹配的响应头。
HTML 本身不能实现 CORS 安全配置——所有所谓“在 HTML 中配 CORS”的尝试，比如 <meta http-equiv="Access-Control-Allow-Origin"> 或硬加 crossorigin 属性，都不构成有效配置，也不改变浏览器行为。真正起作用的只有服务端返回的响应头。
为什么 <meta http-equiv> 对 CORS 完全无效
浏览器明确不解析、不执行任何 Access-Control-Allow-* 类响应头的 <meta> 声明。这类头属于强制校验型响应头，只能由服务器在 HTTP 响应中真实返回。http-equiv 仅支持极少数可被 HTML 解析的头（如 Content-Type、Refresh），CORS 相关字段不在其白名单内。
- 即使你本地改了 HTML、清缓存、换浏览器重开，只要响应头没变，CORS 错误照旧
- 用
file://打开页面或 Live Server 启动，若无后端返回对应头，crossorigin也形同虚设 - 开发者工具 Network 面板里看不到
Access-Control-Allow-Origin，就说明服务端根本没发——前端再怎么改 HTML 都没用
crossorigin 属性的真实作用和触发条件
crossorigin 不是开关，而是“声明加载模式”。它只告诉浏览器：“请按 CORS 流程发起这个资源请求”，但是否成功，完全取决于服务端是否返回匹配的响应头。
-
<img src="https://cdn.example.com/a.jpg" crossorigin="anonymous">→ 浏览器会发带Origin头的请求，若服务端返回Access-Control-Allow-Origin: *，JS 才能调用ctx.getImageData()；否则 canvas 被污染，报 “Tainted canvas” -
<script src="https://cdn.example.com/lib.js" crossorigin="use-credentials">→ 要求服务端必须返回Access-Control-Allow-Credentials: true且Access-Control-Allow-Origin是精确域名（不能为*），否则请求直接失败，连预检都过不去 - 仅对
<img>、<script>、<link rel="stylesheet">、<video>、<audio>有效；<iframe>、<object>不支持该属性
前端能做的唯一有效动作：匹配请求模式与服务端规则
你无法“配”CORS，但可以控制前端行为，避免因错配触发拦截：
立即学习“前端免费学习笔记（深入）”；
- 用
fetch()时显式写mode: 'cors'，尤其搭配credentials: 'include'—— 不写mode可能被降级为no-cors，导致响应体不可读 - 若 API 允许匿名访问，优先用
credentials: 'omit'，这样服务端可安全返回Access-Control-Allow-Origin: * - 开发阶段若服务端未开放 CORS，可用 Vite/Webpack 的
server.proxy把/api/代理到目标地址 —— 注意这只是本地绕过，上线必须依赖服务端正确配置 - 检查 Network 面板中 OPTIONS 请求的响应头：
Access-Control-Allow-Methods是否包含你用的method，Access-Control-Allow-Headers是否覆盖你传的自定义头（如X-Auth-Token）
最容易被忽略的点是：CORS 规则生效有延迟。比如你在阿里云 OSS 控制台刚保存新规则，CDN 缓存或 DNS TTL 可能导致几分钟内仍走旧策略；DCDN 出站响应头还会覆盖 OSS 自身配置，优先看 DCDN 控制台设置。
