理解 location.search 的作用
在前端开发中，window.location 对象几乎每位开发者都不陌生，它能够将当前页面的 URL 信息清晰地分解并展现出来。其中，location.search 属性返回的是从问号（?）开始直至 URL 末尾的部分——即我们所说的查询字符串。通常，它被用来向服务器传递参数，比如搜索关键词或筛选条件。但坦白讲，它的用途远不止充当“传声筒”。只要对查询字符串进行合理解析，前端开发者完全可以在不依赖复杂路由库或框架的前提下，根据参数动态切换页面内容或状态，从而搭建出一套轻量级的“路由”机制。这种方案对于小型项目、原型开发，或者希望在现有静态页面中快速注入一些交互逻辑的场景，都极为适合。
解析查询字符串获取参数
要实现动态切换，首先需要从 location.search 中提取出参数。查询字符串的常见格式通常类似：?key1=value1&key2=value2。编写一个简易的解析函数就能轻松做到。如今，现代浏览器已广泛支持 URLSearchParams 这个 API，用它来获取和操作查询参数十分便捷。举例来说，new URLSearchParams(location.search).get('page') 即可直接获取名为“page”的参数值。如果项目还需要兼容较老的浏览器，那么使用传统的字符串分割法同样有效。解析出的参数，例如页面标识、选项卡索引、筛选条件等，正是后续决定展示什么内容的关键依据。
基于参数控制内容显示
拿到路由参数后，下一步便是根据这些参数动态调整用户界面——本质上就是对 DOM 进行操作。例如，假设我们有一个单页面，其中包含了多个内容板块，查询参数 ?section=profile 表示应当显示用户资料板块。那么我们的 JavaScript 代码可以在页面加载时（或监听 URL 变化时）解析出 section 的值，然后遍历所有板块，将 id 或 data-* 属性与参数值匹配的板块显示出来，同时隐藏其他板块。这种方式模拟了多页应用的路由跳转效果，但所有内容都在同一个 HTML 文件中加载和切换，响应速度自然更快。
同步更新 URL 与历史记录
一套完整的路由机制，不仅要能根据 URL 改变内容，还要在内容变化时同步更新 URL，这样用户才能正常使用浏览器的前进/后退按钮进行导航。当我们在页面上点击按钮切换内容时，应该同时使用 history.pushState() 方法更新地址栏中的查询字符串，并将当前状态添加到浏览器历史记录中。例如，切换到“设置”板块时，将 URL 更新为 当前路径?tab=settings。这样一来，用户复制链接或刷新页面后，看到的仍然是“设置”板块，体验非常流畅。当然，别忘了监听 popstate 事件——当用户点击前进/后退按钮时，要根据变化后的 location.search 重新渲染对应的界面。把这个环节做扎实，才算真正打通了前后端一致的状态闭环。
方案的优势与适用场景
利用 location.search 实现动态路由切换，最大的优势在于简单、零依赖。它无需引入额外的路由库，项目体积和复杂度都得到了控制，特别适合功能相对固定、路由逻辑不复杂的小型应用，或是网站中的某个独立模块。而且，由于参数直接写在 URL 中，特定状态的页面可以被直接收藏或分享，可用性显著提升。不过，这种方法也有其局限性——一旦遇到复杂的嵌套路由，或者需要路由守卫等高级功能，它就显得力不从心了。因此，在决定是否采用此方案之前，最好先评估项目需求、开发效率以及长期维护成本，找到一个合适的平衡点。
