<base> 标签不具备自适应能力，其 href 在 HTML 解析时即固化，无法响应 viewport、网络条件或设备类型变化；真正的自适应资源加载需依赖 <picture>+srcset、动态 import() 或构建时路径注入等机制。
<base> 标签本身不感知“自适应”，它只是粗暴重置 HTML 解析器对后续相对 URL 的基准起点。所谓“自适应网页资源加载”，比如根据屏幕尺寸加载不同分辨率的图片、按设备类型切换 CDN 域名、或按网络条件降级 JS 包——这些行为 <base> 一个都做不到。
base href 不会随 viewport 或 navigator 变化而动态更新
它的 href 值在 HTML 解析开始时就固化了，之后无论用户旋转手机、切到 4G 网络、还是打开 DevTools 模拟 iPad，<base> 都不会重新计算。浏览器不会读取 window.innerWidth 或 navigator.connection.effectiveType 去改写它。
- 你写
<base href="https://cdn-mobile.example.com/">，那桌面端也走这个地址；反之亦然 - 想实现“小屏用 webp、大屏用 avif”，得靠
<picture>+srcset，不是靠<base> - 想按网络条件懒加载非关键 JS？得用
fetch()+import()动态判断，<base>对它们完全无效
真正影响自适应资源加载的，是它和构建/部署策略的配合方式
多数“自适应”效果实际来自构建阶段的路径注入或运行时的 JS 路径决策，<base> 只是其中一环，且极易因配置错位放大问题：
- Webpack/Vite 的
publicPath或build.base设为/mobile/，但 HTML 里漏写<base href="/mobile/">→ 所有<script src="app.js">404 - 你用
<base href="//cdn.example.com/">，但后端 CDN 实际按User-Agent返回不同域名（如cdn-mobile.example.com）→<base>无法转发这个逻辑，JS/CSS 仍发往原始cdn.example.com - 微前端子应用设了
publicPath: "/subapp/"，又加了<base href="/subapp/">→ 资源路径被拼两次：/subapp/subapp/js/chunk.js
CSS 中的 url() 是唯一穿透到样式层的“自适应盲区”
开发者常以为只改 HTML 标签里的 src 和 href 就够了，但 <base> 同样会影响 CSS 里 url() 函数中的相对路径——而这部分往往在媒体查询中用于切换背景图，最容易出错：
立即学习“前端免费学习笔记（深入）”；
-
<base href="/assets/">+@media (max-width: 768px) { .hero { background: url("img/hero-mobile.jpg"); } }→ 实际请求/assets/img/hero-mobile.jpg - 如果构建时把移动端图放到了
/assets/mobile/下，但 CSS 里没同步改路径，就会 404 - 更隐蔽的是：CSS-in-JS 或 CSS Modules 生成的
url()通常由构建工具自动重写，不受<base>影响；但手写的全局 CSS 就会被它劫持
最易被忽略的一点：当你在 <head> 里用 JS 注入 <base> 来“模拟动态 base”，它只对之后新创建的元素生效，已解析的 <link> 和 <img> 完全不受影响——这种“半截子自适应”反而让问题更难定位。
