html本身不配cors，cors由服务器响应头（如access-control-allow-origin）控制；meta标签无效，因浏览器只校验http响应头而非html标签；fetch、xmlhttprequest等主动请求才触发cors校验，而普通默认不触发。
直接说结论：HTML 本身不配 CORS，CORS 是服务器响应头控制的，前端写 <script></script> 或 <img> 不触发 CORS，但 fetch、XMLHttpRequest、WebSocket 等主动请求会受浏览器强制校验。
为什么在 HTML 里加 meta 标签没用
很多人试过在 里加 <meta http-equiv="Access-Control-Allow-Origin" content="*">，这完全无效。因为 Access-Control-Allow-* 系列响应头必须由服务器在 HTTP 响应中返回，浏览器只认响应头，不认 HTML 的 meta 标签。
- 浏览器只检查实际 HTTP 响应头里的
Access-Control-Allow-Origin、Access-Control-Allow-Methods等字段 -
meta http-equiv模拟的是Content-Type或Refresh这类可被 HTML 解析的头，不包括 CORS 相关头 - 哪怕你用 Express、Nginx、OBS 或 DCDN 配了 CORS，只要后端没正确返回对应头，前端页面再怎么改 HTML 都没用
哪些前端操作会真正触发 CORS 校验
不是所有跨域资源加载都走 CORS。只有满足「跨域 + 浏览器主动发起的脚本请求」才会触发预检（OPTIONS）或简单请求校验。
-
<img src="https://other.com/a.jpg?x-oss-process=image/resize,p_40">：不触发 CORS（除非加crossorigin属性） -
<script src="https://other.com/lib.js"></script>：默认不触发，但若加crossorigin="anonymous"，就要求服务端返回Access-Control-Allow-Origin -
fetch('https://api.other.com/data')：一定触发，无论是否带凭据 -
XMLHttpRequest请求跨域接口：一定触发 - 使用
withCredentials: true或credentials: 'include'时，Access-Control-Allow-Origin不能为*，必须精确匹配 origin 字符串
OBS / OSS / DCDN 这类对象存储怎么配 CORS
如果你用的是阿里云 OSS、华为云 OBS 或 DCDN 托管静态资源或 API，CORS 必须在控制台或 API 里配置规则，不是改前端代码能解决的。
- OBS 控制台路径：
桶 > 概览 > 创建 CORS 规则，最多 100 条 - 关键字段要对齐前端请求：
-
允许的来源：填具体域名如http://localhost:3000，别填*（如果用了credentials） -
允许的方法：至少包含GET、POST、OPTIONS（预检必须） -
允许的头域：如果前端发了Content-Type、Authorization，这里就得显式列出 -
缓存时间：设成0或600（秒），避免本地调试时规则不刷新
-
- DCDN 场景下，如果源站是 OSS，DCDN 的出站响应头配置会覆盖 OSS 的 CORS 设置，优先看 DCDN 控制台的「修改出站响应头」页签
常见报错和对应修复点
看到控制台报错，先盯住错误信息里的关键词，它基本指明了哪一环没对上。
-
Response to preflight request doesn't pass access control check: The value of the 'Access-Control-Allow-Origin' header... must not be the wildcard '*'：说明前端用了credentials: 'include'，但服务端返回了Access-Control-Allow-Origin: *。改成返回请求头里的Origin值（如ctx.set('Access-Control-Allow-Origin', ctx.headers.origin)） -
The value of the 'Access-Control-Allow-Credentials' header in the response is '' which must be 'true'：服务端漏了Access-Control-Allow-Credentials: true响应头 -
Request header field content-type is not allowed by Access-Control-Allow-Headers：前端发了Content-Type: application/json，但服务端的 CORS 规则里没把Content-Type加进允许的头域 - OPTIONS 请求 404 或 502：后端没实现 OPTIONS 路由（如 Koa/Express 没挂
app.options()中间件），或反向代理（如 Nginx）没透传 OPTIONS 请求
真正容易被忽略的是：CORS 规则生效的前提是请求能抵达目标服务器。如果中间有 CDN、WAF、Nginx、负载均衡器，它们可能拦截或改写响应头——得一层层确认每个环节是否透传或覆盖了 CORS 头。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
