css中url()受影响仅发生在html解析阶段，即拼接为/base/路径，之后css引擎不再重新解析；纯相对路径才生效，@import、image-set()等不受控。
CSS文件内的url()函数会受<base>影响，但仅限HTML解析阶段
HTML中<base href="/assets/">对CSS里background: url(logo.png)起作用，但这个“起作用”只发生在浏览器加载该CSS文件的那一刻——即HTML解析时把url(logo.png)拼成/assets/logo.png，之后CSS引擎自己不再重新解析。这不是CSS主动读取document.baseURI，而是HTML解析器提前帮你算好了。
-
url()里的路径必须是纯相对路径（不以/、:或协议开头），否则<base>完全不介入；写成url(/images/logo.png)或url(https://cdn/logo.png)就绕过它 - 如果CSS是通过
<link href="theme.css">引入的，那theme.css自身的路径不影响url()拼接逻辑——拼的是<base href>+url()里的字符串，不是theme.css所在目录 - Firefox对根相对
href结尾斜杠特别敏感：<base href="/app">（缺/）会导致url(css/brand.svg)被错误拼成/appcss/brand.svg
@import语句完全不受<base>控制
@import "reset.css"或@import url(common.css)中的路径，始终以当前CSS文件所在URL为基准解析，和<base>无关。哪怕你写了<base href="/cdn/">，reset.css还是从/css/reset.css（假设主CSS在/css/main.css）去加载。
- 这是CSS规范层的行为，HTML解析器不参与
@import路径计算 - 想统一CDN前缀，得靠构建工具重写
@import路径，或改用绝对URL：@import "https://cdn.example.com/v2/reset.css" - 动态
import()、fetch()、new CSSStyleSheet()创建的样式表也都不走<base>逻辑
容易踩的坑：你以为url()受控，其实只是“碰巧生效”
很多开发者看到<base href="/v2/">后background: url(icon.png)能加载，就以为所有CSS路径都归它管。但只要换一种写法，立刻失效：
-
background-image: image-set("icon-1x.png" 1x, "icon-2x.png" 2x)→ 不受控，image-set()是CSS运行时函数，不经过HTML解析 -
content: url(arrow.svg)→ 受控（同url()），但content: attr(data-icon)→ 不受控，值由JS注入，已脱离HTML解析上下文 - 用
style属性内联写：<div style="background:url(logo.png)"> → 受控；但<code>element.style.background = 'url(logo.png)'→ 不受控真正安全的替代方案比依赖
<base>更可控如果你的目标是让所有资源走CDN或子路径，硬靠
<base>风险太高：它只管一小部分路径，又极易因部署路径、浏览器差异或构建配置错位而静默失败。- 构建时替换：Webpack用
publicPath、Vite用build.base，直接生成带前缀的src/href和CSS内url()，无需<base> - CSS变量+JS注入：
:root { --asset-base: "/cdn/"; }，然后background: url(var(--asset-base) + "logo.png")（注意：需配合CSS.supports('background', 'url(var(--x))')降级） - 服务端渲染时动态写
<base>：确保它只出现在构建产物中，且与路由base、Service Worker缓存路径严格对齐，避免多处重复声明
url()受<base>影响，是HTML解析器“替你提前拼了一次”，不是CSS引擎持续监听baseURI。一旦页面加载完成，这个拼接动作就结束了——后续任何JS修改document.baseURI或动态插入<base>，对已加载的CSS毫无意义。 - 构建时替换：Webpack用
