BOM与History/Location：浏览器API

可视化演示

展示BOM对象层次结构、History API历史栈操作与Location URL解析，交互切换三种模式理解浏览器API核心机制。

BOM核心概念

你买下第一辆智能汽车，坐进驾驶舱时，最先看到的是车企印在说明书上的“驾驶舱全景图”：方向盘、仪表盘、后视镜、中控屏各有位置、各司其职。浏览器里的 BOM（Browser Object Model，浏览器对象模型）就是这张全景图。它把浏览器窗口抽象成一组彼此协作的对象：谁是总指挥，谁管当前地址，谁记录历史，谁描述运行环境，全都安排得明明白白。你不需要自己发明体系，只需要学会按图索骥。

DOM 和 BOM 的分工是很多新手的第一道坎。打个比方：DOM 是车载中控屏上正在播放的那部电影——它管的是页面的内容结构；而 BOM 是承载这块屏幕的整个驾驶舱——它管的是浏览器窗口本身。更微妙的是，document 既是 DOM 的根节点，同时也作为 window 的一个属性挂在 BOM 名下。换句话说，电影既属于播放器，也属于整车电气系统。

BOM 的核心是 window 对象。location、history、navigator、screen、document 全都是 window 的子属性。你写的全局变量和全局函数，最终也都会挂载到 window 上。正因如此，前端调试时在控制台敲一个 window.location.href，就等于在问“GPS 屏上当前显示的路段是什么”。不同浏览器对 BOM 的实现细节有差异，这引出了开发中最重要的习惯——先做兼容性检测，再大胆使用新 API。

所以，当你对面试官说“我理解 BOM”时，其实是在说：“我熟悉这个驾驶舱里每一个仪表的位置、读数和操作方法。”

window全局对象

驾驶舱的正中央是一块总控面板。你按下的每个按钮、读取的每个数值，最终都汇集到这块面板上。window 就是浏览器驾驶舱里的总控面板：它既是全局变量的注册中心，也是定时器、弹窗、滚动控制这些基础按钮的所在位置。

在 JavaScript 中，全局作用域下声明 var x = 1 之后，你完全可以在另一个地方写 window.x 取到同一个值。这是因为浏览器把全局变量都挂在了 window 这个属性仓库里。这种设计的代价是：全局变量太多会互相污染，就像中控台上堆满杂物，想找哪个按钮都费劲。因此现代前端开发推崇模块化，尽可能少往 window 上挂东西。

window 还掌管着三类高频操作。第一类是定时器：setTimeout 像是车厢里的“一次性闹钟”，到点提醒一次；setInterval 像是“循环播放”按钮，每隔固定时间重复执行。第二类是弹窗交互：alert、confirm、prompt 是浏览器内置的三块提示牌，适合简单场景，但 UX 粗糙，生产环境要慎用。第三类是窗口控制：通过 window.innerWidth 与 innerHeight 可以读取视口尺寸，用 window.scrollTo 可以控制滚动位置，这就像查看挡风玻璃的尺寸、按下座椅调节键。

总控台虽好，但不要把所有设备都堆在它上面。模块化 + 命名空间，才是老司机的收纳哲学。

Location导航地址

开车去陌生城市，你会把目的地输进导航。导航屏上显示：当前在哪条路、门牌号多少、经由哪条匝道、有没有备注。Location API 就是浏览器这辆车的 GPS 屏，它用一组属性把当前 URL 拆解成清晰的路段信息。比如 https://shop.app/products?page=2#reviews 这串地址，在 location 眼中是一组带标签的零件。

location.protocol 是协议头，相当于 GPS 的“卫星信号通道”（https 还是 http）；location.host 是域名加端口，相当于“城市与街道”；location.pathname 是路径，相当于“门牌号”；location.search 是查询字符串，像快递面单上的备注；location.hash 是锚点，相当于楼内的具体房间号。你在控制台分别打印这些属性，就能像看导航数据一样把 URL 拆得明明白白。

Location 的另一个职责是做跳转。location.assign(url) 是规规矩矩开车到新地址，会留下历史记录；location.replace(url) 是走同一条路但把当前出发点从行车记录仪上抹掉，用户按返回键不会回到这里；location.reload() 则是原地重启发动机，重新加载当前页面。最特别的是 hash：修改它不会刷新页面，却会在历史栈里新增一条记录——这个特性让它成为前端路由的基石，后面 SPA 一节你还会见到它。

GPS 屏上每个数字都有意义，Location 的每个属性也一样。会读会改，你的页面导航就成功了一半。

History历史栈

行车记录仪默默记下你走过的每个路口，你可以回放某一段，也可以随时掉头回到某个位置。History API 就是浏览器这辆车的记录仪，它维护着一个“历史栈”——一个你或许听过但有点怕的术语。别担心，它就像自助餐厅里的一摞盘子：新盘子总是放到最上面，要拿只能从最上面取，后进先出。

传统页面跳转就像换了一条路：每点一个链接，浏览器都要重新加载整条路的路况信息，页面白屏、状态丢失，体验生硬。History API 给出了更优雅的方案：history.pushState(state, title, url) 可以把一条新记录“无声无息”地压入栈顶，同时更新地址栏的 URL，但页面完全不刷新。这就像在导航仪上切换到一条新路线预览，车本身还在原地，没有重新启动。

history.replaceState 则替换当前栈顶的记录而不新增，适合“修正”当前状态而不是留下新足迹的场景。那监听什么呢？当用户点击浏览器的前进/后退按钮时，浏览器会触发 popstate 事件，并把当初 pushState 时存入的状态对象（state）交还给你。有趣的是：直接调用 pushState 或 replaceState 并不会触发 popstate，只有用户主动前进后退才会触发。这与“按下记录仪的播放键不会自动倒带，手动拨动进度条才会”是同一个道理。

记录仪不会说谎，历史栈里每一条都真实可查。理解它的读写规则，你就能精准操控浏览器的“前进后退记忆”。

Navigator环境识别

每辆车的副驾储物格里都有一本随车手册，记录着发动机型号、排量、出厂年份、支持的功能列表。Navigator 就是浏览器的随车手册——一个描述“我是谁、我在什么环境里运行”的配置单对象。

navigator.userAgent 是一个长字符串，包含浏览器名称、版本号、内核信息，江湖人称“浏览器身份证”。过去前端靠解析它来判断“用户用的是不是 Chrome”，但这条路的坑很多：Chrome 的 UA 里就藏着 Mozilla、Safari 等字样，直接匹配容易翻车。更现代的思路是特性检测：不问他叫什么名字，直接问他能不能做某件事。比如判断浏览器是否支持 History API，写 'pushState' in history 比检测 UA 可靠得多——就像判断一辆车能不能跑山路，与其看车标，不如直接试试它的悬挂系统。

Navigator 还提供几个高频实用信息：navigator.platform 返回操作系统平台（Win32、MacIntel 等），navigator.onLine 告诉你当前网络是否在线，navigator.language 返回浏览器界面语言。在开发国际化站点或离线功能时，这些字段就像随车手册里的环境适配建议，缺一不可。

先看配置单再开车，先查 navigator 再做功能。这条准则能让你的代码在五花八门的浏览器里都走对路。

SPA前端路由

想象你在一条高架路上匀速行驶，道路本身没有变化，但导航屏上的目的地画面不断切换——这就是单页面应用（SPA）的体验。SPA 的灵魂是“不刷新页面，就能换一块屏幕内容”，而实现这个魔术的，正是前端路由，它实际上就是在“导航与记录仪”之间做协同编排。

前端路由有两大主流模式。第一种是 hash 模式：URL 写成 https://site.app/#/about，把路由路径放在 # 之后。因为修改 hash 不会刷新页面又会在历史栈留下记录，天然契合 SPA。浏览器还提供了 hashchange 事件，只要 hash 一变，页面就能收到通知并重新渲染。第二种是 History 模式：借助 pushState 把 URL 改成没有 # 的干净路径（比如 /about），看起来和传统网站一模一样，但对服务器有额外要求——用户刷新 /about 时，服务器必须把请求回退到 index.html，否则会得到 404。

以 hash 路由为例，实现思路非常朴素：监听 hashchange 事件，取出 location.hash 中的路径，查路由表，渲染对应组件。Vue Router、React Router 的底层逻辑本质上就是这句话的工程化放大。History 模式则依赖 popstate 事件和 state 对象来传递路由参数，让“前进后退”时组件状态也能恢复回来。

掌握了这两套模式，你就像同时学会了“导航界面切换”和“仪表盘布局切换”两种手法，遇到任何路由需求都能从容应对。

兼容性与实践

同样是驾驶舱，特斯拉和五菱宏光的按钮布局完全不同。浏览器市场也是如此：Chrome、Firefox、Safari、Edge 各有各的怪脾气。BOM 相关的 API 兼容性差异，处理不好就会让你的页面在某类设备上“熄火”。老司机的做法是提前做好三件事：特性检测、降级方案、安全边界。

第一，特性检测优先。在使用 pushState 前，先检查 'pushState' in history；需要监听 hash 变化时，先确认浏览器支持 hashchange 事件。与其问“你是不是 Chrome”，不如问“你能不能做到这件事”。第二，降级方案兜底。如果浏览器不支持 History 模式，就自动退回 hash 模式；实在不行，就退回传统的整页刷新。这就像山路太陡时，自动从两驱切换成四驱。第三，守好安全边界。pushState 只允许同源 URL，跨域会抛异常；跳转时警惕恶意 URL 的钓鱼陷阱；从 URL 读取的参数要校验后再使用，防止注入攻击。

性能优化方面也有讲究：监听 scroll、resize 这类高频事件时要加节流（throttle），路由懒加载则能让首屏只渲染必要的组件，不至于一启动就把所有页面都载入内存。这些细节就像给驾驶舱做定期保养，短时间看不出差别，跑长途就见真章。

能驯服不同车型的车手，才是真正的老司机。兼容性不是束缚，而是让你在更广阔的路况下都能安全抵达。

AI 应用场景

Python 演示

from urllib.parse import urlparse  class BrowserHistory:    def __init__(self):        self.entries = ["/home"]        self.index = 0     def push(self, new_path):        self.entries = self.entries[: self.index + 1]        self.entries.append(new_path)        self.index += 1     def back(self):        if self.index > 0:            self.index -= 1        return self.entries[self.index]     def forward(self):        if self.index < len(self.entries) - 1:            self.index += 1        return self.entries[self.index]     def current(self):        return self.entries[self.index]  def parse_location(full_url):    parts = urlparse(full_url)    return {        "protocol": parts.scheme,        "host": parts.netloc,        "pathname": parts.path,        "search": parts.query,        "hash": parts.fragment,    }  if __name__ == "__main__":    bh = BrowserHistory()    bh.push("/about")    bh.push("/contact")    print("current:", bh.current())    print("back ->", bh.back())    print("forward ->", bh.forward())     loc = parse_location("https://store.app/products?page=2#reviews")    for key, value in loc.items():        print(key, ":", value)

1. self.entries = self.entries[: self.index + 1]新入栈时先截断当前索引之后的记录，模拟浏览器“跳到新路线后旧的前进记录作废”的行为。
2. bh.push("/about")相当于前端调用 history.pushState，把新路径压入栈顶。
3. bh.back()相当于 history.back()，返回上一页；越界时停留在栈底。
4. parse_location("https://store.app/products?page=2#reviews")模拟 location 对象把完整 URL 拆解成 protocol、host、pathname 等部件。
5. parts.fragment解析出的片段就是前端 location.hash 对应的内容，体现 hash 在 URL 中的独立地位。

常见误区

面试题