<base> 标签与CORS完全无关，仅影响相对URL解析起点；真正触发CORS校验的是crossorigin属性及服务端响应头配对。
<base> 标签和跨源资源共享（CORS）完全无关，它既不触发、不绕过、也不影响任何 CORS 检查。
base 标签根本不管 CORS 逻辑
<base> 只在 HTML 解析阶段重写纯相对路径（如 logo.png、app.js）的解析起点，仅作用于 <img src>、<script src>、<link href>、<form action> 和 CSS 中的 url()。这些加载行为本身就不走 CORS 流程——浏览器默认允许跨域加载图片、脚本、样式表，只要不读响应体。
换句话说：<base href="https://cdn.example.com/"> 可能让 <img src="icon.png"> 最终请求 https://cdn.example.com/icon.png，但这个请求是否成功，只取决于 CDN 是否返回有效的 Access-Control-Allow-Origin 响应头（如果加了 crossorigin 属性），跟 <base> 本身毫无关系。
crossorigin 属性才是 CORS 的开关，base 完全不参与
真正决定是否启用 CORS 校验的是 crossorigin 属性本身，且必须和服务端响应头配对：
立即学习“前端免费学习笔记（深入）”；
-
<img src="photo.jpg" crossorigin="anonymous">→ 浏览器发带Origin头的请求，服务端需返回Access-Control-Allow-Origin: *或具体域名 -
<script src="lib.js" crossorigin>（等价于crossorigin="anonymous"）→ 同样触发 CORS，否则 JS 错误堆栈会被屏蔽 -
<link rel="stylesheet" href="theme.css" crossorigin>→ 加了才能用 JS 读取document.styleSheets[0].cssRules
<base> 不会改变 crossorigin 的行为，也不会让没加该属性的标签突然开始校验 CORS。
常见混淆点：base 写错 ≠ CORS 报错
很多人遇到资源 404，又看到控制台有 CORS 错误，就以为是 <base> 导致的。其实两者独立：
-
<base href="static/">（无效写法）→ 浏览器静默忽略，所有src="app.js"按当前页面 URL 拼，结果 404；控制台报Failed to load resource，不是 CORS -
<img src="https://api.example.com/photo.jpg" crossorigin>+ 服务端没回Access-Control-Allow-Origin→ 控制台明确报Blocked by CORS policy，跟<base>是否存在、值是多少完全无关 -
<base href="/sub/">+<script src="main.js" crossorigin>→ 请求地址是/sub/main.js，但 CORS 校验仍只看该 URL 的响应头，base 不提供、不伪造、不覆盖任何响应头
真正容易被忽略的边界情况
最危险的不是搞混 base 和 CORS，而是误以为 base 能“统一解决路径和跨域问题”。实际上：
- 动态创建的
<img>元素（如document.createElement('img')）不受<base>影响，它的src解析始终以当前文档 URL 为基准 -
fetch('./api/data')、import('./utils.js')、@import "reset.css"全部绕过<base>，它们的路径解析逻辑和 CORS 行为都由 JS/CSS 引擎独立处理 - 如果你在子路径部署 SPA（如
/admin/），又手动写了<base href="/admin/">，但忘了给fetch('/api/user')加前缀，那请求仍会发到根路径/api/user—— 这不是 CORS 问题，是路径拼错
