摘要

  • <base href> 为 HTML 文档中的相对地址设定解析起点。链接里仍写着 chapter.html，完整目的地却会随基地址改变。
  • 1995 年的 HTML 2.0 用它帮助脱离原始位置的文档认路；后续规范明确了优先级、首个元素规则和 base-uri 约束。

路牌写着“前面一条街”。字没有错，箭头也没掉。有人悄悄把地图换成了另一座城，“前面一条街”便指向新地方。HTML 的 <base href> 就是网页里的地图原点。正文里的短链接无需逐一改写，浏览器会从页头指定的起点算出它们的完整地址。

这个设计最早有个朴素用途。1995 年 11 月的 RFC 1866，也就是 HTML 2.0，说明 BASE 可在文档脱离原始环境时，替相对 URL 提供一个基地址。网页被复制、邮寄，或从别处打开，images/logo.gif 还在那里；可它该从哪台机器的哪个目录取？把绝对基地址写进文档，网页就能把自己的方向感一并带走。RFC 还用图片路径举例，让读者看见这套地址算法怎样落地。

1999 年 12 月的 HTML 4.01把次序说得更明白。BASE 放在文档的 HEAD，而且要赶在引用外部资源的元素之前。它设定的地址优先于协议交互带来的元数据，再优先于文档本身的位置。链接、图片、样式表、表单处理地址，都可能写成相对路径。标准用 ../cages/birds.gif 演示：同样的字串，在另一基地址下会落到另一条完整路径。页头一行，给许多路牌指定了同一个起点。

2005 年 1 月的 RFC 3986从整个 URI 体系解释这种层级：内容中嵌入的基地址，高于外层容器的地址，也高于取回内容时使用的地址。这让通过邮件或归档转手的文档保留原意。RFC 3986 讲的是一般解析规则；HTML 的 base 元素则是网页执行这条规则的具体方法。网页“从哪里取到”与网页“从哪里解释短链接”可以是两回事。前者没动，后者一换，路就变了。

WHATWG 维护中的 HTML 标准给出清楚例子：<base href="/book/"> 会使 href="chapter.html" 指向 /book/chapter.html。没有这个声明时，浏览器用文档的后备基地址解析。假如页面里有多个带 href 的 base 元素，第一个生效。target 还能另行指定链接和表单默认在哪个浏览位置打开；它也有自己的“第一个生效”规则。两个属性各管一件事，不能一句“只有第一个标签有用”就糊弄过去。

浏览器也会检查地图原点。现行算法遇到无效地址、data: 或 javascript: 作为基地址时，会退回文档的后备地址。文档的安全策略还可以拦下不允许的基地址。W3C 的 CSP Level 2 引入 base-uri，让发布者限定哪些 URL 可以扮演这个起点；该指令不会自动从 default-src 继承。一个管方向的总开关，配上一个限制它能指向哪里的护栏。

维护者喜欢总开关，理由充分：网站搬家时，改一处地址比改十处链接轻松得多。风险也从同一处长出来。基地址写错，许多链接一起拐弯；读者看到的 chapter.html 本身，无法交代它究竟在哪座城。浏览器把短字串、页头的基地址和可能存在的策略拼在一起，才算出点击会走到哪里。

1995 年，它帮离家出走的网页记住老家。1999 年，标准明确让作者的声明占优。今天，解析和限制更细致。始终没变的是这笔交易：一群短地址共用一个出发点。搬走出发点，路牌不用动，整张地图照样改写。