1 基础概念
1.1 单页应用的定义
单页应用是指以单个 HTML 页面作为载体，通过前端脚本动态更新内容和界面的一类 Web 应用。与传统多页面网站相比，单页应用在用户操作过程中通常不会频繁触发整页刷新，而是通过局部更新实现页面切换和交互反馈。
这类应用往往将界面拆分为多个可复用组件，并在客户端完成大部分渲染与状态控制。因此，单页应用通常更强调前后端分工，页面结构、交互逻辑和数据流转主要由前端承担。
1.2 路由的基本作用
路由用于根据不同访问条件展示不同内容，是单页应用中的导航核心。它负责把某个地址、路径或状态变化，映射到相应的视图、组件或页面模块。
在实际应用中，路由不仅承担“切换页面”的作用，还会影响权限控制、数据加载、页面缓存和历史记录管理。可以说，路由是用户感知到的导航体验与程序内部状态之间的桥梁。
1.3 URL 与视图的映射关系
在单页应用中，URL 不再仅仅表示服务器上的物理文件位置，而是用来表达当前应用状态的一种外部标识。不同的路径、查询参数或哈希值，通常对应不同的视图内容。
这种映射关系使得用户可以通过地址栏直接定位到特定界面，也便于收藏、分享和回退操作。与此同时，前端路由系统会根据 URL 变化，决定加载哪个组件、显示哪种布局，以及如何传递相关参数。
1.4 前端路由与后端路由的区别
后端路由主要由服务器处理，请求到达后由服务器根据地址选择响应内容，通常返回完整页面或数据结果。前端路由则运行在浏览器端，负责在页面已加载的前提下，控制视图切换和地址变化。
两者的差异集中在执行位置与作用阶段。前者侧重请求响应，后者侧重交互导航；前者决定资源如何返回，后者决定界面如何呈现。在单页应用中，前端路由通常与后端接口协作，共同完成完整的应用体验。
2 工作原理
2.1 History API 模式
History API 模式利用浏览器提供的历史记录接口，在不刷新页面的情况下修改地址栏内容。它通过更自然的路径形式模拟传统网站的访问方式，因此在多数现代 Web 应用中使用较多。
该模式依赖浏览器对历史栈的支持，并结合前端拦截和监听机制来完成页面切换。由于地址表现更接近常规链接，它也更利于搜索引擎收录和用户理解。
2.1.1 pushState 与 replaceState
pushState 用于向历史记录中新增一条状态，同时更新当前地址而不触发页面刷新。用户随后可以通过浏览器“后退”返回到之前的状态。
replaceState 则会替换当前历史条目，不新增记录。它适合用于纠正地址、修正参数或在跳转过程中避免产生多余的历史痕迹。两者共同构成了 History 模式中地址管理的基础。
2.1.2 popstate 事件
当用户点击浏览器的前进或后退按钮时，浏览器会触发 popstate 事件，通知页面历史状态发生变化。路由系统可以借助这一事件重新解析当前路径，并更新对应视图。
这一机制使得单页应用能够响应浏览器原生导航行为，而不仅仅依赖脚本内部跳转。对于复杂应用来说，正确处理 popstate 是保证导航一致性的关键环节。
2.2 Hash 模式
Hash 模式通过 URL 中的片段标识部分实现路由切换，通常表现为“#”后面的内容变化。由于片段标识不会被传统服务器当作完整请求路径处理，因此这种方式较易部署。
在单页应用早期，Hash 模式因实现简单、兼容性较强而被广泛采用。即使在现代环境中，它仍适用于一些部署条件较为受限的场景。
2.2.1 锚点标识与哈希变化
哈希部分原本用于页面内锚点定位，例如跳转到某个章节位置。在路由系统中，这一特性被扩展为状态标识，开发者可通过修改 hash 值来触发视图切换。
当 hash 变化时，浏览器通常不会重新请求页面，而是只改变地址片段。前端可以监听这一变化并进行路由匹配，从而实现无刷新导航。
2.2.2 浏览器兼容性特点
Hash 模式兼容性通常较好，能够在较多旧版浏览器中稳定运行。由于它对服务器配置要求较低，部署过程也相对简单。
不过，哈希地址的表现形式不如路径模式自然，链接外观也较长。在需要更美观地址结构或更强 SEO 适配时，开发者往往会优先考虑其他方案。
2.3 路由匹配机制
路由匹配用于判断当前访问路径应当进入哪个规则分支。系统通常会按照预设的路由表，对路径进行逐层比对、提取参数并选择对应组件。
匹配机制的设计直接影响路由系统的可维护性与扩展性。路径是否清晰、规则是否冲突、兜底是否明确，都会影响最终的导航表现。
2.3.1 静态路径匹配
静态路径匹配是最直接的方式，即路径字符串完全一致时视为命中。例如固定首页、关于页或帮助页，通常采用这种简单规则。
静态匹配逻辑清晰，性能开销也较低，适合结构稳定的页面。对于路由表来说，静态规则通常优先级较高，能减少歧义。
2.3.2 动态参数匹配
动态参数匹配允许路径中的某一段作为变量使用，例如用户编号、文章编号或分类名称。路由系统会在匹配成功后提取这些值，并传递给页面组件。
这种方式提升了路由的复用能力，使同一个组件可以处理多个实例页面。它是内容详情页、列表详情页等场景中常见的设计。
2.3.3 通配符与兜底规则
通配符规则用于匹配不确定路径，常见用途是处理不存在的页面、嵌套层级过深的路径或特殊重定向需求。兜底规则则在没有其他匹配项时提供默认响应。
这类规则有助于提升容错能力，避免用户因输入错误地址而直接看到空白页面。常见做法是展示 404 页面、引导页或默认首页。
3 路由配置
3.1 路由表结构
路由表是路由系统的核心配置集合，通常以数组、对象或声明式规则的形式描述路径与组件之间的对应关系。它决定了应用中可访问的导航结构。
一个完整的路由表往往还会包含重定向、嵌套层级、元信息和权限标记等内容。随着应用规模扩大，路由表会逐渐成为前端架构的重要组成部分。
3.1.1 路径定义
路径定义用于指定某个路由的访问地址。它可以是固定字符串，也可以包含动态参数、通配符或层级结构。
清晰的路径命名有助于保持项目结构一致，并降低后续维护成本。一般来说，路径应尽量语义化，避免过度冗长或难以理解的组合。
3.1.2 组件映射
组件映射指把某个路径对应到具体的页面组件或视图模板。路由命中后，系统会将对应组件渲染到指定位置。
这种映射关系通常是单页应用实现模块化的关键。组件既可以是完整页面，也可以是局部区域的展示单元，从而形成灵活的界面组织方式。
3.1.3 重定向配置
重定向配置用于将某个路径自动跳转到另一个路径。它常见于默认首页设置、旧地址兼容和访问规范统一等场景。
合理使用重定向可以减少重复页面，也能让用户更快到达目标内容。若配置过多，则可能增加跳转链条，影响可读性和维护效率。
3.2 嵌套路由
嵌套路由用于表达父级页面与子级页面之间的层级关系。它适合处理具有明显模块分区的界面，如后台管理、文章详情页内的多个标签页等。
通过嵌套路由，应用可以在保持公共布局不变的同时，只更新局部内容。这种机制有利于提高复用率，也让页面结构更符合业务逻辑。
3.2.1 父子路由关系
父路由通常负责提供整体框架，例如导航栏、侧边栏或主布局；子路由则负责填充具体内容区域。两者结合后，可以形成层次分明的页面结构。
这种关系让公共部分与变化部分分离，便于统一维护。父级组件不必因子页面切换而重复渲染，用户体验也更连贯。
3.2.2 子视图渲染位置
子视图渲染位置指子路由内容在父级布局中的插入点。不同框架通常会提供专门的占位容器，用于承载子页面输出。
如果渲染位置设计合理，页面结构会更加清晰，布局切换也更加自然。反之，若插槽层级混乱，容易导致组件关系难以追踪。
3.3 命名路由
命名路由是通过名称而非直接路径来引用路由的一种方式。它在路径较长、层级较深或参数较复杂时尤其有用。
使用命名路由可以减少硬编码字符串带来的维护风险。相比直接写路径，按名称跳转通常更稳定，也更容易随路由结构调整而同步更新。
3.3.1 路由命名规范
路由命名一般强调唯一性、可读性和层级一致性。常见做法是按照模块、页面或业务域进行命名，避免同名冲突。
良好的命名规范有助于团队协作，也方便调试和日志排查。若命名含义模糊，后期修改路径时容易产生引用错误。
3.3.2 通过名称跳转
通过名称跳转时，开发者只需指定路由名及必要参数，路由系统会自动解析对应路径。这样做可以降低对具体 URL 结构的依赖。
在实际项目中，这种方式常用于表单提交后的跳转、列表详情联动和跨模块导航。它尤其适合需要频繁调整目录结构的应用。
4 导航与跳转
4.1 声明式导航
声明式导航是通过模板或组件标签来表达跳转意图的一种方式。它更接近页面结构描述，适合静态链接和常规入口。
这种方式的优点是语义直观，代码可读性较好，且通常与浏览器原生链接行为较为接近。对于大多数普通导航场景，它已经足够使用。
4.1.1 链接组件
链接组件通常用于生成可点击的路由入口，并在内部处理地址更新和历史记录。与普通 a 标签相比，它往往会拦截默认刷新行为，转而由前端完成跳转。
这类组件能统一导航样式和行为，减少手写事件处理的重复工作。很多框架还会为其扩展预取、激活态或无障碍支持。
4.1.2 当前路由高亮
当前路由高亮用于标识用户所在位置，常见于菜单、标签页和面包屑导航中。它通常依据当前路径与目标路径的匹配结果自动切换样式。
高亮状态有助于增强方向感，让用户更容易理解自己所处的页面层级。合理的视觉反馈也能减少误操作和重复点击。
4.2 编程式导航
编程式导航是通过脚本直接触发路由切换的方式。它适合在业务逻辑完成后、事件回调中或条件判断后执行跳转。
相比声明式导航，编程式方式更灵活，可以在跳转前做更多处理，例如校验、拼接参数、保存状态或执行提示。
4.2.1 路径跳转
路径跳转是最基础的编程式导航，即直接指定目标地址完成切换。它适合目标明确、结构简单的场景。
在实现上，系统会更新 URL 并通知路由实例重新渲染对应组件。若配合历史记录管理，还可保留正常的前进后退体验。
4.2.2 带参数跳转
带参数跳转通常用于在跳转时传递业务信息，如编号、筛选条件或临时状态。参数可以出现在路径中、查询字符串中或路由状态中。
这种方式能让目标页面直接读取上下文信息，减少重复查询。需要注意的是，公开可见的参数应避免携带敏感内容。
4.2.3 替换历史记录
替换历史记录指在跳转时不新增一条历史条目，而是直接修改当前项。它常用于登录后跳转、默认页纠正或临时中间页清理。
这种处理方式能让历史栈更整洁，避免用户返回到不需要的中间状态。若使用不当，也可能让“后退”行为与预期不一致。
4.3 导航控制
导航控制用于管理前进、后退以及中断等行为，是复杂路由流程中的安全阀。它让应用能够在特定条件下阻止无效跳转或延迟进入。
在包含权限、表单编辑、异步加载等场景时，导航控制尤为重要。它既关系到数据安全，也关系到用户体验。
4.3.1 返回与前进
返回与前进对应浏览器历史栈的基本操作。路由系统通常需要与这些原生行为协同工作，以保持页面状态一致。
当用户通过按钮、快捷键或浏览器控件切换历史时，应用应及时更新视图。若历史状态与页面状态不同步，容易产生混乱。
4.3.2 跳转中断与取消
跳转中断与取消是指在路由尚未完成切换前，基于某些条件停止进入目标页面。常见原因包括权限不足、未保存更改或数据校验失败。
这一机制可以防止用户误入不合适页面，也能保护当前编辑内容。合理设计中断逻辑，通常能显著降低操作风险。
5 路由参数
5.1 路径参数
路径参数是嵌入在 URL 路径中的变量部分，常用于标识某个资源实例。它使同一套页面模板能够服务多个具体对象。
路径参数是单页应用中最常见的参数形式之一，尤其适用于详情页、分类页和可枚举资源页面。
5.1.1 动态段解析
动态段解析是从路径中提取变量值的过程。路由系统会在匹配规则时识别这些占位段，并将实际内容映射到参数对象中。
这种解析方式使页面组件不必关心完整地址，只需读取参数即可获得当前上下文。对于列表到详情的跳转链路，这一设计非常常见。
5.1.2 参数校验
参数校验用于确认路径参数是否符合预期格式，例如数字、日期、固定枚举或合法字符范围。若校验失败，系统可能重定向或显示错误页。
适当的校验可以降低异常访问带来的影响，也有助于避免无效请求继续深入处理。对于关键资源路径，校验尤为必要。
5.2 查询参数
查询参数位于 URL 的问号后面，通常用于补充筛选条件、分页信息或非核心状态。它在不改变主路径的前提下，提供更多可选信息。
与路径参数相比，查询参数更适合表达可变条件，也更适合多个参数并存的情况。它常见于搜索、筛选和列表控制页面。
5.2.1 查询字符串读取
查询字符串读取是从 URL 中解析键值对的过程。路由系统会把这些信息整理为可访问对象，供页面逻辑使用。
在实现上，通常需要处理缺省值、重复键和编码转换等问题。若读取方式统一，组件间的数据交互会更加清晰。
5.2.2 默认值处理
默认值处理是指当某些查询参数缺失时，为其补充预设值。例如分页页码、排序规则或筛选范围，常需要回落到默认状态。
这种处理能减少页面空白或逻辑分支过多的问题。良好的默认值策略还可以让链接共享更稳定，避免因参数不全导致展示异常。
5.3 哈希参数
哈希参数通常出现在片段标识部分，可用于表示页面内部状态、局部定位或轻量级导航信息。它在某些旧式方案和特殊交互中仍有使用价值。
由于哈希不参与常规请求路径，相关参数处理方式与路径和查询参数略有不同，需要单独考虑解析逻辑。
5.3.1 片段标识读取
片段标识读取是从“#”后面提取内容，并将其解释为状态或定位信息。路由系统会据此决定是否需要跳转到特定区域。
这种做法常与页面内锚点、标签切换或轻量路由结合使用。虽然简单，但在复杂业务中仍需注意同步与维护成本。
5.3.2 特殊字符处理
哈希内容也会涉及编码、转义和特殊符号问题。若字符处理不当，可能导致解析失败、链接失真或展示异常。
因此，在拼接与读取哈希参数时，通常需要进行统一编码规则管理。这样既能保持兼容性，也能避免字符歧义。
6 路由生命周期
6.1 路由进入前
路由进入前阶段发生在目标页面真正渲染之前。此时系统通常会先做条件判断，再决定是否允许进入。
这个阶段适合处理权限、预加载和资源准备等工作。若提前完成必要检查，可减少进入后再回退的额外开销。
6.1.1 权限检查
权限检查用于判断当前用户是否具备访问目标页面的资格。它可以基于登录状态、角色标签或功能开关进行控制。
在很多应用中，权限判断会在路由层统一处理，以减少各组件重复编写验证逻辑。这样不仅更一致，也更便于维护。
6.1.2 数据预取
数据预取是在进入页面前提前请求必要数据，避免页面渲染后出现长时间空白。它常用于详情页、表单编辑页和需要初始化配置的界面。
预取机制能让用户更快看到完整内容，但也会带来一定等待成本。因此，预取策略通常需要结合缓存、并发和失败兜底一起设计。
6.2 路由切换中
路由切换中阶段是从旧视图转向新视图的过渡期。这个阶段既可能出现加载等待，也可能涉及动画和状态同步。
良好的切换体验能够降低“页面闪烁”感，让导航过程更平滑。对于交互复杂的应用，切换中状态是提升品质的重要细节。
6.2.1 加载状态显示
加载状态显示用于提示用户当前页面正在切换或数据尚未就绪。常见形式包括骨架屏、进度条、旋转图标或局部占位内容。
适当的反馈可以减少用户对卡顿的误解，也能缓解等待时的焦虑。若加载时间较短，反馈设计应尽量简洁，避免打扰浏览节奏。
6.2.2 过渡动画处理
过渡动画处理用于在页面切换时加入视觉变化，使新旧内容之间的衔接更自然。它可以表现为淡入淡出、滑动、缩放或层级切换。
动画如果控制得当，能提升界面的精致感；若过于频繁或冗长，则可能影响效率。通常应结合内容类型和使用场景谨慎选择。
6.3 路由离开后
路由离开后阶段发生在用户离开当前页面之后。此时需要处理与页面相关的副作用，避免残留状态影响后续操作。
这一阶段看似收尾，却对应用稳定性很重要。尤其在表单、定时器、订阅监听或临时缓存场景中，离开后的清理不可忽视。
6.3.1 清理副作用
清理副作用包括取消监听、关闭定时任务、移除事件绑定和清除临时变量等。它的目标是防止旧页面逻辑继续运行。
若不及时清理，可能出现重复请求、内存增长或意外更新界面的情况。对生命周期管理要求较高的应用，这一步尤其关键。
6.3.2 资源释放
资源释放是指在页面离开后回收不再使用的数据、缓存或对象实例。它有助于控制内存占用，并维持应用长期运行的稳定性。
在大型单页应用中，资源释放策略往往与缓存策略并存，需要在性能与占用之间取得平衡。
7 高级特性
7.1 路由守卫
路由守卫是对导航过程进行拦截、检查和处理的机制。它可以在路由进入前、切换中或离开时执行逻辑判断。
这类机制常用于权限控制、表单保护和条件跳转。它让路由系统不仅负责“去哪儿”，也负责“能不能去”。
7.1.1 全局守卫
全局守卫作用于所有或大部分路由，适合处理统一的登录状态、标题设置和基础校验。其优点是集中管理，规则一致。
如果全局逻辑过多，也可能使路由流程变得复杂。因此，通常只保留最通用、最关键的检查项。
7.1.2 局部守卫
局部守卫只对某一条路由或某一组路由生效，适合特殊页面的个性化限制。它能让规则更贴近业务需求。
与全局守卫相比，局部守卫更灵活，也更容易表达页面特定逻辑。常见例子包括编辑页离开确认、敏感页面访问控制等。
7.1.3 异步守卫
异步守卫会先完成异步判断，再决定是否继续导航，例如等待接口返回、权限确认或配置加载。它特别适合依赖远程数据的场景。
由于异步过程存在延迟，设计时需要考虑超时、失败和用户反馈。若处理不当，容易造成跳转停滞或重复触发。
7.2 懒加载与代码分割
懒加载与代码分割用于将应用拆成多个按需加载的模块。这样可以减少初始加载体积，提高首屏响应速度。
在路由层面，这通常表现为进入某个页面时才下载对应组件资源。对于规模较大的应用，这是一项非常实用的性能优化手段。
7.2.1 按路由拆包
按路由拆包是根据页面或模块边界生成独立资源包。访问不同页面时，浏览器只加载当前需要的部分。
这种方式可以显著降低一次性加载压力，也便于版本更新和缓存管理。它是现代前端构建流程中的常见实践。
7.2.2 首屏性能优化
首屏性能优化的目标是让用户尽快看到可用内容。路由懒加载、资源预取、缓存策略和布局拆分都可能影响首屏表现。
在实际项目中，首屏与后续页面体验需要同时考虑，不能只追求一次性小体积。合理的平衡往往比单纯压缩更有效。
7.3 滚动行为管理
滚动行为管理用于控制页面切换后滚动位置的恢复与调整。它能帮助用户保持阅读上下文，减少频繁回到顶部带来的中断感。
对于长列表、文档阅读和多层详情页来说，这一能力尤为重要。路由系统往往会结合浏览器历史和页面锚点共同处理。
7.3.1 记忆滚动位置
记忆滚动位置是指在返回某页面时恢复之前的浏览位置。它可以提升连续浏览体验，尤其适用于信息流和长内容页面。
若没有该机制，用户往往需要手动重新定位，体验会明显下降。很多框架会提供默认或可定制的滚动恢复策略。
7.3.2 锚点滚动
锚点滚动用于让页面自动定位到指定区域，通常与 URL 片段或目录导航结合使用。它常见于帮助文档、长篇介绍页和分节内容页面。
这种方式既能提高定位效率，也能让链接直接指向具体内容。要注意目标元素的加载时机，否则可能出现定位失败。
7.4 路由过渡动画
路由过渡动画是专门用于页面间切换的视觉效果。它与一般组件动画不同，更强调导航上下文中的整体连贯性。
合适的过渡设计能让应用看起来更顺滑，也能帮助用户感知页面层级变化。对于重交互产品来说，这类动画往往具有一定的界面辨识度。
7.4.1 进入动画
进入动画用于新页面出现时的视觉表现，常见形式包括淡入、位移进入和缩放展开。它可以增强页面切换的层次感。
进入动画通常不宜过长，以免影响操作效率。若与数据加载同时进行，还需避免视觉和内容出现错位。
7.4.2 离开动画
离开动画用于当前页面退出时的收束效果，帮助旧内容平稳过渡到下一个视图。它常与进入动画配合使用，形成完整的切换节奏。
离开动画的设计重点在于自然与克制。过强的动画可能分散注意力，而适度的过渡更能体现界面一致性。
8 典型应用场景
8.1 后台管理系统
后台管理系统通常包含菜单导航、权限分级和多层功能页面，非常适合使用单页应用路由。路由可以帮助实现模块切换、面包屑定位和局部内容更新。
在这类场景中，嵌套路由和权限守卫尤其常见。它们能让复杂功能区保持结构清晰，同时减少重复布局。
8.2 内容型网站
内容型网站通常包含文章列表、详情页、分类页和标签页，路由规则较为清晰。通过路径参数和查询参数，可以方便地表达内容分类与筛选条件。
这类网站更注重可读地址和浏览连续性。良好的路由设计能够提升分享体验，也利于用户深度阅读。
8.3 单页面产品官网
单页面产品官网常用于展示产品介绍、功能亮点和注册入口，通常具有较强的视觉一致性。路由可以用于控制不同展示模块、专题页或局部跳转。
在这类场景中，过渡动画和锚点滚动较常见。它们有助于增强品牌感，并提升浏览过程的流畅度。
8.4 交互式工具与仪表盘
交互式工具与仪表盘往往需要在同一应用内切换多个功能面板，并保持状态同步。路由可用于管理不同工具页面、分析视图和配置面板。
这类应用通常依赖历史记录、参数传递和缓存机制，以便用户在多个操作步骤之间自由切换。路由设计是否合理，会直接影响使用效率。
9 常见问题
9.1 直接刷新 404
在 History 模式下，用户直接刷新某个子路径时，浏览器会向服务器发起真实请求。若服务器没有正确配置回退规则，就可能返回 404。
这是单页应用中最常见的部署问题之一，通常与前端路由和服务器资源映射方式有关。
9.1.1 服务端重写规则
服务端重写规则的作用，是让非静态资源请求回到应用入口页，再由前端路由接管解析。这样即使刷新深层地址，也能正常进入应用。
这类配置通常属于部署层面的关键步骤。不同服务器环境写法不同，但目标一致，都是把路由控制权交还给前端。
9.1.2 静态托管配置
静态托管环境中，平台通常提供自定义回退或重定向配置。只要将未知路径指向入口文件，就能避免刷新时报错。
对于托管在对象存储或静态站点平台上的应用，这项配置尤其重要。否则，前端路由虽然可用，直接访问却可能失败。
9.2 参数丢失或解析异常
参数丢失或解析异常往往出现在跳转、编码或路径设计不当时。表现形式可能是参数为空、乱码、截断或无法识别。
这类问题通常与 URL 拼接方式、转义规则和路由匹配规则有关，需要从生成与读取两端一起排查。
9.2.1 编码与解码问题
URL 中的特殊字符需要经过合适编码，否则可能在传输过程中被误解读。常见问题包括空格、中文、符号分隔导致的解析偏差。
统一编码和解码策略，可以显著减少此类错误。尤其在跨页面传参时，更需要保证参数格式前后一致。
9.2.2 路径冲突
路径冲突是指多个路由规则在形式上过于接近，导致系统难以准确判断命中哪一条。动态参数与静态路径混用时，这种问题更容易出现。
解决方式通常是调整规则优先级、细化路径命名或增加限定条件。清晰的路由设计可以减少冲突带来的不确定性。
9.3 路由重复渲染
路由重复渲染通常表现为同一页面组件被重新创建或反复刷新，导致性能下降或状态丢失。它可能由复用策略不当、 key 变化或缓存失效引起。
这类问题在列表详情切换、同组件不同参数切换时比较常见。若处理不佳，用户会感觉页面“闪一下”或表单内容被清空。
9.3.1 组件复用策略
组件复用策略用于决定同一个组件在不同路由之间是否继续复用实例。复用得当，可以减少不必要的销毁与重建。
但若页面依赖路由参数变化来更新内容，就需要同步处理数据刷新逻辑。否则组件虽未重建，内容却可能停留在旧状态。
9.3.2 缓存与销毁机制
缓存与销毁机制决定了页面离开后是保留状态还是完全清除。缓存能提升返回速度，销毁则更有利于释放资源和避免旧数据残留。
在实际项目中，这两种策略往往需要按页面类型区分使用。编辑页与阅读页的处理方式通常就不完全相同。
9.4 首屏加载缓慢
首屏加载缓慢通常与资源体积过大、依赖过多或初始化逻辑复杂有关。由于单页应用往往需要先加载脚本再渲染内容，首屏体验尤其敏感。
优化这类问题，通常要同时从构建、缓存、路由拆分和资源请求几个方面入手。
9.4.1 按需加载
按需加载可以减少初次进入时的资源下载量，只在需要时加载相关模块。路由懒加载是其中最常见的实践之一。
通过减少首屏包体积，应用通常能更快进入可交互状态。对于模块较多的项目，这往往是最直接的优化手段。
9.4.2 预加载策略
预加载策略是在用户即将访问某页面前，提前准备相关资源。这样在真正切换时，等待时间会明显缩短。
预加载应当控制节奏，避免过度抢占带宽或造成无效请求。合理使用时，它能够在性能与体验之间取得较好的平衡。
10 相关概念
10.1 组件化开发
组件化开发是将界面拆分为独立、可复用单元的开发方式。它与路由系统配合紧密，因为路由通常负责决定哪些组件在何时组合展示。
在单页应用中，页面切换本质上往往是组件的动态装配。组件化越成熟，路由结构通常越清晰。
10.2 状态管理
状态管理用于统一维护应用中的共享数据、页面状态和交互结果。它与路由常常相互配合，例如记录登录信息、筛选条件或页面缓存状态。
当路由切换较频繁时，状态管理能帮助保持数据连续性。它使多个页面之间的数据协作更稳定，也更容易调试。
10.3 服务端渲染
服务端渲染是指页面初始内容由服务器先行生成，再交给浏览器接管。它在首屏展示、搜索可见性和初次加载体验方面具有一定优势。
与单纯客户端渲染相比，服务端渲染对路由、数据预取和水合流程要求更高。两者结合时，需要更仔细地协调页面初始化过程。
10.4 静态站点生成
静态站点生成是在构建阶段预先生成 HTML 文件，使页面可以直接由静态资源提供。它适合内容相对稳定的网站，也常用于文档站和营销页。
在路由层面，静态站点生成通常要求路径结构更明确，并提前确定可生成页面范围。这样既能获得较好的访问性能，也便于部署维护。