别只盯着 DOM：搞定 BOM 才能掌控浏览器交互的全局

很多前端开发者刚入行时，容易陷入一个误区：觉得 JavaScript 的核心就是操作 DOM 节点。改个 class、添个 style、监听个点击事件，这确实是日常工作的大头。但一旦涉及到页面跳转、获取用户设备信息、或者处理浏览器窗口本身的尺寸变化，单纯靠 DOM 就会卡壳。这时候，你就得真正理解 BOM（Browser Object Model）了。

DOM 解决的是“页面里有什么”，而 BOM 解决的是“浏览器本身能干什么”。它是连接 JavaScript 代码与浏览器内核的桥梁。所有涉及浏览器环境的操作，起点都是那个最大的全局对象——window。

地址栏里的秘密：Location 对象

最常用也最容易踩坑的，莫过于 location 对象。它直接映射浏览器的地址栏。除了大家熟知的 location.href 用来做跳转外，更值得深挖的是它的解析能力。

当你需要从 URL 参数中获取数据时，不要总想着引入 heavy 的第三方库。原生 location.search 返回的就是包含查询字符串的部分，比如 ?id=1&name=test。配合 URLSearchParams API（现代浏览器支持良好），你可以优雅地提取参数：

const params = new URLSearchParams(window.location.search);
const userId = params.get('userId');

这种方式比正则表达式靠谱得多，且兼容性在当下已无压力。另外，修改 location.hash 往往用于实现单页应用的锚点定位，它不会引起页面重载，适合记录当前滚动位置或标签页切换状态，而不会在浏览器历史栈里留下冗余记录。

导航控制的艺术：History 对象

在做后台管理系统或 SPA（单页应用）时，history 对象的重要性不言而喻。传统的 back() 和 forward() 方法虽然好用，但在控制历史记录的状态上比较粗暴。

核心思路是利用 pushState 和 replaceState。 它们允许你在不刷新页面的情况下修改 URL，并向历史栈中添加或替换一条记录。这对于保持用户体验的流畅度至关重要。不过要注意，使用 popstate 事件来监听浏览器前进后退的动作是必要的，否则你的路由逻辑会失控。记住，修改历史栈是双向的，既要考虑怎么推入新状态，也要想好怎么响应状态回退，这才是完整的路由体验。

设备指纹与环境检测：Navigator 与 Screen

判断用户是用手机还是电脑访问，是移动端适配的前置条件。很多人习惯直接读取 navigator.userAgent，但这其实是个过时的方案。UA 字符串太长且容易被伪造，维护起来极其痛苦。

更务实的做法是特性检测。与其猜测用户是谁，不如测试他支持什么。比如，想要判断是否移动端，可以通过触摸事件的支持情况 (ontouchstart in window) 来辅助判断。

至于屏幕尺寸，这里有个经典的认知偏差。window.innerWidth 代表的是视口宽度（即内容可见区域），而 screen.width 才是物理屏幕的真实宽度。在制作全屏应用或响应式布局时，务必分清这两个概念。如果你需要根据物理像素做高清屏适配，应该去读 window.devicePixelRatio，而不是盲目依赖 screen 的数值。

那些被浏览器限制的权限

最后必须提一下安全限制。随着隐私保护意识的提升，浏览器对 BOM 的控制越来越严。比如 window.open 打开新窗口，如果不是由用户直接的点击行为触发的（例如自动定时弹窗），大概率会被广告拦截器屏蔽。这意味着在设计分享功能或登录回调时，必须将弹窗逻辑绑定在明确的交互事件下，否则代码写得再漂亮也没用。

BOM 不是炫技的工具，而是解决实际问题的武器。当你不再把 window 仅仅当作一个容器，而是视为整个运行环境的控制器时，你会发现很多关于页面通信、存储、导航的难题都能找到原生解法。DOM 负责让页面“好看”，BOM 负责让页面“好用”，两者结合，才是一个成熟前端该有的视野。