1 基本概念
1.1 定义
Hash 模式是一种基于 URL 片段标识符的前端路由方式。它通常利用地址中 # 之后的内容来表示当前页面所处的视图、模块或状态，并借助浏览器对哈希变化的监听机制，在不重新请求整页资源的情况下完成页面切换。
在单页应用中，Hash 模式常被视为一种轻量级路由方案。由于 # 后面的内容不会作为普通请求路径发送到服务器，因此前端可以在客户端自行解析并控制页面展示逻辑。
1.2 发展背景
Hash 模式的出现，与早期 Web 应用对动态交互和浏览体验的需求增长密切相关。传统多页应用每次跳转都需要向服务器请求新页面，交互成本较高；而随着前端脚本能力增强，开发者开始希望在浏览器中直接管理页面视图。
在浏览器对现代历史 API 支持尚不普及的时期，哈希片段因兼容性较好、实现门槛较低，成为前端路由的常见选择。它既能保留一定的地址变化特征，又避免了服务端重写配置带来的复杂度。
1.3 核心特征
Hash 模式的核心，在于将 URL 的片段部分作为应用内部状态的载体。它的路由行为主要由浏览器端脚本控制，页面切换通常不依赖服务器参与。
1.3.1 URL 片段标识
哈希位于 URL 的 # 之后，常用于标记当前页面位置或路由路径。例如，#/home、#/about 之类的写法，都可以被前端程序解释为不同视图入口。由于这一部分属于片段标识，浏览器会把它与主路径区分开来处理。
1.3.2 客户端路由
在 Hash 模式下，路由判断主要发生在客户端。页面并不一定整体刷新，而是通过脚本根据哈希值决定加载哪个组件、显示哪块内容，或更新哪些状态。这使得界面切换更接近应用内部导航，而不是传统网页跳转。
1.3.3 无需服务器重写支持
Hash 模式的一个重要特性，是通常不需要服务器做额外的重写配置。无论用户访问哪个哈希路径，服务器一般只会返回同一个基础页面，再由前端根据 # 后面的内容完成二次分发。这也使其在静态部署环境中尤为常见。
2 工作原理
2.1 哈希值的生成与读取
哈希值通常由前端脚本设置，也可以由用户直接在地址栏中输入或通过链接跳转生成。浏览器会把 # 后的内容保留在当前 URL 中，并提供接口让脚本读取这一部分值。
开发者一般通过 location.hash 获取当前哈希，并根据需要对其进行解析、清洗或映射，从而决定应用应该呈现的页面状态。
2.2 hashchange 事件
当 URL 中的哈希部分发生变化时，浏览器会触发 hashchange 事件。前端程序可以监听这一事件，在变化发生后更新路由状态、切换视图或执行相关逻辑。
这一机制是 Hash 模式能够实现无刷新导航的基础之一。只要哈希变化被正确捕获，页面就可以在局部范围内完成“跳转”效果。
2.3 路由匹配流程
Hash 模式的路由流程通常比较直接：先获取哈希，再根据预设规则匹配目标页面，随后渲染对应内容，并同步应用状态。
2.3.1 路径解析
路径解析阶段会把 # 后的字符串提取出来，必要时去除多余符号、分隔参数或规范化格式。例如，将 #/user?id=1 拆分为主路由与附加参数，便于后续匹配。
2.3.2 视图渲染
完成路径识别后，路由系统会加载对应组件或模板。对于单页应用来说，这一步通常表现为局部 DOM 更新，而不是整页刷新。不同框架的实现方式略有差异，但基本思路一致。
2.3.3 状态同步
除了页面内容切换，路由系统还需要维护应用内部状态，例如当前菜单高亮、页面标题、面包屑信息或历史记录顺序。状态同步做得越完整，用户感知到的导航体验就越连贯。
3 应用场景
3.1 单页应用
Hash 模式最典型的应用场景是单页应用。此类应用通常只加载一次基础 HTML 和脚本资源，随后所有页面切换都由前端完成。Hash 路由在这里能很好地承担视图切换和状态管理任务。
3.2 页面锚点导航
哈希本身也常用于页面锚点定位，例如跳转到长文档中的某个章节或表单位置。即便不作为路由使用，它仍可借助浏览器原生能力快速定位到指定区域。
3.3 旧浏览器兼容方案
在部分较早期浏览器环境中，Hash 模式常被当作较稳妥的路由实现方式。相比依赖较新历史 API 的方案，哈希机制通常更容易被识别和支持，因此适合作为兼容性较强的基础方案。
3.3.1 兼容性处理
兼容性处理通常包括检测浏览器对事件监听、地址栏更新和历史栈操作的支持情况，并据此决定是否启用哈希路由。若环境能力有限，开发者会尽量采用最基础的解析与渲染逻辑。
3.3.2 降级策略
当更高级的路由方案无法稳定工作时，项目可能回退到 Hash 模式，以保证核心导航功能可用。此类降级策略强调可访问性与稳定性，牺牲的是部分地址美观度和语义表达能力。
4 优势与局限
4.1 优势
Hash 模式之所以长期流行，主要在于其实现成本低、上手快，并且在多数环境中具有较好的可用性。
4.1.1 实现简单
Hash 路由的基础逻辑不复杂，只需监听哈希变化并进行映射即可。对小型项目或快速原型开发而言，这种实现方式通常足够直接。
4.1.2 部署方便
由于一般不依赖服务器重写配置，Hash 模式在静态托管环境中部署较为方便。上传基础文件后，只要前端脚本正常运行，路由功能就能工作。
4.1.3 兼容性较好
哈希机制属于浏览器较早支持的功能之一，因此在较广泛的运行环境中表现稳定。对于需要照顾老旧设备或低配置环境的项目，它具有一定吸引力。
4.2 局限
Hash 模式并非没有缺点。它在表达方式、检索效果和复杂路由扩展方面，都存在一定限制。
4.2.1 URL 可读性不足
由于路径信息被放在 # 后面，整体地址往往不如传统路径那样直观。某些复杂写法还会让链接显得冗长，影响分享和理解体验。
4.2.2 搜索引擎友好度有限
哈希内容通常不作为标准请求路径参与服务器处理，因此在搜索引擎抓取和索引方面常受限制。对于依赖自然检索流量的网站来说，这一点尤其需要考虑。
4.2.3 复杂路由能力受限
当应用存在多层嵌套、精细化权限、复杂参数组织或高级路由策略时，Hash 模式的表达能力可能显得不够灵活。此时，开发者往往会考虑更完善的路由方案。
5 与其他路由模式的比较
5.1 与 History 模式的区别
History 模式依赖浏览器历史 API，通过更接近真实路径的方式管理导航，URL 通常更简洁自然。相比之下，Hash 模式以 # 片段作为状态载体，实现更简单，但地址语义稍弱，且在 SEO 上通常不占优势。
5.2 与查询参数模式的区别
查询参数模式常通过 ?key=value 的形式传递页面状态，强调参数化表达；Hash 模式则更多将片段视为路由入口。前者适合少量筛选、检索和条件控制，后者更常用于页面级视图切换。
5.3 与服务端路由的区别
服务端路由由服务器根据请求路径决定返回内容，页面跳转通常伴随完整刷新。Hash 模式则把控制权更多交给客户端，服务器只需提供基础资源，实际页面切换由前端逻辑完成。
6 实现机制与常见写法
6.1 基础监听方式
常见实现会在页面初始化时读取当前哈希，并监听 hashchange 事件。每次哈希更新后，程序根据新值执行对应处理函数，完成视图切换。
6.2 路由表设计
路由表通常以键值映射形式存在：键表示路径，值对应页面组件、回调函数或渲染逻辑。通过这种结构，路由分发过程会更清晰，也便于维护和扩展。
6.3 默认路由处理
当地址栏没有有效哈希，或者哈希不匹配任何已定义路径时，系统一般会跳转到默认路由。常见做法包括重定向到首页、展示欢迎页，或者进入统一的兜底页面。
6.4 路由参数传递
Hash 模式可以通过路径段、查询串或片段内部自定义格式传递参数。开发时通常会对这些参数做解析与校验，以便在目标视图中正确使用。
7 开发实践
7.1 前端框架中的使用
在现代前端框架中，Hash 路由一般由专门的路由库统一管理。开发者只需配置路由表、页面组件和导航规则，即可快速构建应用的页面结构。
7.2 路由守卫与权限控制
Hash 路由同样可以配合路由守卫实现登录校验、权限判断和访问拦截。进入某些页面前，系统会先检查用户状态，再决定是否允许继续跳转。
7.3 404 与异常页面处理
对于未命中路由的情况，通常需要设计 404 页面或异常提示页。这样不仅能提升容错性，也有助于用户理解当前页面为何无法访问。
7.4 性能与体验优化
为了提升体验，开发者常会结合懒加载、缓存、预取和页面过渡动画等手段，减少切换时的等待感。虽然 Hash 模式本身较轻量，但合理优化仍然能显著改善整体流畅度。
8 常见问题
8.1 哈希变化不触发页面刷新
哈希变化本身通常不会导致整页刷新，这是 Hash 模式被广泛采用的重要原因之一。若项目希望在变化后执行更新逻辑，需要显式监听相关事件并手动处理。
8.2 首次加载状态初始化
页面首次打开时，必须读取当前哈希并完成初始化，否则可能出现地址与视图不一致的情况。常见做法是在应用启动阶段先进行一次路由解析，再挂载对应内容。
8.3 浏览器前进后退行为
浏览器的前进、后退按钮会影响哈希历史记录。只要路由监听正常，应用就能跟随历史栈变化同步切换页面状态，从而保持导航连贯。
8.4 与锚点冲突处理
当哈希既被用于路由，又被用于页面锚点时，可能出现冲突。开发中通常会通过统一格式约定、区分用途标记或封装跳转方法来减少歧义。