现代 Web 应用已转移了重心。页面不再是系统——运行时才是。像 React、Angular、Vue、Next.js、SvelteKit、Remix 和 Nuxt 这样的框架把 HTML 当作引导加载器，真正的应用只有在完成 hydration、路由、数据获取和持续重渲染之后才会出现。用户的体验完全依赖于 JavaScript 的执行，而不是静态的标记。
团队通常在界面看似已加载但什么都无法操作时才发现这种变化。按钮无响应，面板保持空白，流程在没有明显服务器端错误的情况下中断。路由器——而不是页面——决定了应用是否真正可用，然而大多数监控工具从未观察到它。
如果您在 SPA、CSR、SSR 或混合架构上依赖以页面为中心的监控，那么您是在观察外壳而不是应用。本文阐述了如何正确监控由路由驱动的系统，以及为什么合成流和 RUM 必须跟随运行时而不是初始 HTML。
页面加载后的监控
在多页面应用中，页面生命周期就是应用生命周期。您会测量加载时间、DOM 就绪、错误和服务器响应。依赖关系是稳定且可见的。
客户端路由打破了这一假设。首次加载只是众多加载中的一次。真正的故障现在出现在浏览器不会重置的状态中：动态组件树、累积的 store 数据、fetch 缓存、路由守卫、功能开关以及在不重新加载 URL 的情况下从一个逻辑“页面”切换到另一个逻辑“页面”的过渡。如果您的监控在 DOMContentLoaded 就停止了，您将错过 90% 的运行时情况。
运营问题变为：如何衡量一个在用户切换屏幕时不再“重新启动”的应用？
答案是：跟随路由器。
为什么客户端路由会破坏传统监控模型
路由框架会拦截导航事件，在原位渲染新视图，并对远程服务发起异步调用。URL 可能会改变，也可能不会。DOM 可能部分更新，也可能完全重新渲染。不存在“页面完成”的概念。只有“视图已挂载”、“数据已解析”和“store 已更新”。
传统的可用性检查假设：
- 一次全新的页面加载。
- 确定性的 HTML 响应。
- 交互之前的完整 DOM。
这些假设在 SPA/CSR 架构中都无法成立。路由切换可能会失败，而 URL 看起来却有效。组件可能会挂载，而它的数据层却已损坏。功能开关服务可能会为不同的人群返回不同的 payload，导致渲染极其不一致，合成监控必须检测到这些情况——而不是将其忽略为“暂态”问题。
监控变得以行为为中心，而非基于文档。您不能再只是检查一个 URL，而必须验证一次体验。
架构光谱：SPA、CSR、SSR、SSG 与混合
Web 开发已经分化为一个渲染模型的光谱：
- 纯 SPA/CSR 加载单个 HTML 页面并将一切交给 JavaScript。导航完全由客户端驱动。UserView 风格的监控必须理解执行过程，而不是页面。
- SSR 框架（Next.js、Nuxt、SvelteKit）带回了服务器端渲染的首屏，但对后续导航使用客户端路由。结果：首次绘制表现得像传统多页面应用，但之后的每次交互都像 SPA。
- SSG 与 ISR 预先生成静态 HTML，但 hydration 仍决定应用是否可用。静态页面可能看起来正确，而其水合后的组件却静默失败。
- 混合模型 可按路由或按环境混合模式。未登录用户可能得到 SSR，而已登录用户可能得到 CSR。
架构仅影响首次渲染。监控必须关注随后发生的运行时。
SPA/CSR 应用中的真实故障模式
由路由驱动的应用引入了传统监控从未见过的新类别故障。
hydration 失败很常见：HTML 外壳渲染出来，但 JavaScript 遇到服务端渲染标记与客户端渲染标记不匹配。应用看起来活着，但实际已冻结。
路由器初始化失败会在路由定义冲突、懒加载模块无法加载或路由器无法解析当前状态时出现。用户看到的是一个功能性的外壳，但没有内容。
状态存储损坏会在 Redux、Vuex、NgRx、Zustand 或其他存储跨导航携带格式错误的状态时出现。由于 SPA 累积状态而不是重置它，故障会出现在多步骤流程的深处——恰好是大多数监控停止测量的地方。
静默的 API 故障发生在路由成功导航但数据层返回 500 或 403 响应时。视图加载了，但显示不完整或为空的控件。监控必须将其视为故障，而非退化的成功。
过时的 bundle 是持续的威胁。CDN 常常提供过时的 JS，导致版本不匹配，从而使 hydration 或路由崩溃。这些故障在不同地区表现不同，合成监控尤为擅长检测它们。
这些故障模式都发生在页面加载之后。大多数仅在用户执行一系列操作后才出现。如果您的监控模型不包含多步骤的合成流，您将在用户投诉之前看不到这些问题。
在强路由框架中衡量导航
在 SPA 中无法通过等待 DOM 稳定来判定导航是否成功。运行时从不会稳定。
相反，监控必须测量：
- 从用户操作（点击/触摸）到路由视图的时间。
- 组件挂载完成，而非文档就绪。
- 数据解析——必要的 XHR/fetch 调用是否完成，且 UI 是否已消费这些数据？
- UI 确认——页面是否真正渲染了预期的交互状态？
“加载时间”指标变得无意义。关键是转场延迟、hydration 完整性和数据依赖完整性。
监控必须观察用户旅程的时间线，而不是文档的生命周期。
针对多步骤路由流的合成监控
监控由路由驱动的应用需要完整的浏览器执行，而不是轻量级的 HTTP 检查。路由转场不表现为页面加载，许多脚本化浏览器测试会失败，因为它们假设 URL 可预测地变化或 DOM 状态静态。合成流必须像真实用户一样行为：点击、导航、交互以触发路由。它还必须识别路由事件，即便 URL 保持不变，跟踪 DOM 在组件更新时的变动，并跟随每次转场触发的异步工作。
最重要的是：测试必须确认 UI 实际达到了预期状态。这意味着观察数据层的解析，等待依赖数据的已挂载组件，并验证渲染后的界面，而不是计时文档加载。这是判断路由视图是否完整且可用的唯一可靠方法。
故障常常隐藏在步骤之间。一个 SPA 可能多次成功导航，然后由于状态累积、内存压力或路由守卫的边缘情况最终破坏流程。这些是用户遇到的问题，但简单监控从未看到过。这就是为什么面向路由的合成测试已经成为必需基础设施而非可选项。
监控路由背后的 API 层
SPA 将后端视为一组微服务。导航会触发对以下服务的 API 调用：
- GraphQL 端点
- REST 服务
- 搜索和推荐引擎
- 功能开关服务
- 个性化端点
- 认证和授权层
路由可能成功，而底层 API 却失败。从用户角度看，应用已经崩溃，即便外壳已加载。
监控必须将路由成功与服务成功相关联。如果 UI 加载了组件但因为某个 API 响应缓慢或错误而无法填充，合成流必须将其视为失败。否则，监控会呈现绿色仪表盘，而用户却被卡在半渲染的屏幕上。
缓存、CDN 与 bundle 维度
由路由驱动的应用比传统服务器渲染站点更依赖 CDN 和资源管线，整个体验的稳定性依赖于 bundle 的完整性。当缓存规则配置错误、ETag 或版本哈希发生漂移，或某个 CDN 区域提供了过时的 chunk 时，即便服务器持续返回 200-OK，路由也可能出错。这些故障会表现为 HTML 与 JavaScript 之间的 hydration 不匹配、页面加载了正确的外壳但执行了错误的 bundle，以及懒加载模块失败，因为其对应的 chunk 不再匹配当前的构建。
这些问题很少在全球范围内一致出现。某个区域可能接收到最新的资源，而另一区域滞后数分钟或数小时，造成仅部分用户体验到的不一致行为。并且由于 SPA 依赖“预热”的运行时，许多故障只会在一系列导航后显现，而非在干净的首次加载时暴露。
监控必须能够揭示这些不一致性。单区域测试或始终以冷启动页面为起点的合成检查会错过大多数与 CDN 相关的路由故障。只有多区域、具状态的合成流才能提供可靠的防护，因为它们暴露了用户实际看到的 bundle 与缓存行为——而非监控工具常常假设的简化版本。
正确监控 SSR 与混合框架
SSR 引入了一个常见盲点：服务器渲染的 HTML 看起来正确，因此团队假设监控已覆盖。但 SSR 只是框架的一半。hydration 必须成功，用户交互才能可用。如果 hydration 失败，页面就是一张没有交互的明信片。
监控必须分离：
- SSR 性能与可用性
- hydration 完整性
- CSR 导航性能
- 预热导航的稳定性
混合框架使情况更复杂。单一路由可能会因身份认证状态、地理位置、A/B 测试分配或功能开关的不同而表现不同。
这意味着合成监控必须评估多种用户画像。单一登录流程不足以覆盖。单一路由路径也不足以覆盖。混合模型会在您的脚下改变行为，监控必须遍历用户可能采取的所有路径。
真正对 SPA 有效的合成监控策略
有效的监控采用以行为、运行时为导向的模型。
您模拟驱动路由的用户交互，而不是测量服务器发送了什么。您等待可见结果，而不是 DOM 就绪。您自动观察 API 调用，而不是手动检查。您将缺失的控件内容视为故障，而不是可接受的部分成功。
捕获控制台日志的监控会揭示 hydration 错误、路由器崩溃和动态导入失败。跟踪 XHR/fetch 的工具会揭示藏在成功导航背后的数据故障。对渲染 UI 的断言确保应用按用户期望工作，而不仅仅是服务器的响应。
监控成为观察运行时正确性的透镜，而不是页面正确性的透镜。
RUM + 合成：路由框架的组合可见性模型
RUM（真实用户监控）提供真实世界的有机性能数据。它揭示区域性降级、设备差异、长尾延迟和用户行为模式。
合成监控提供确定性的工作流、一致的回归检测和受控条件。
由路由驱动的应用需要两者。
单独的 RUM 无法检测未来的回归。单独的合成无法捕获真实世界的可变性。两者结合，构成了 SPA 和混合应用的完整监控表面：
- 合成测试提前发现故障。
- RUM 确认影响范围。
- 合成测试复现问题。
- RUM 验证修复。
这一良性循环对动态改变行为的复杂前端至关重要。
版本漂移、发布速度与合成监控的角色
现代前端构建流水线不断生成新版本，部署系统经常不均匀地分发这些版本。CDN 边缘可能需要数分钟来清除过时资源，ISR 页面可能以不同间隔再生，滚动发布可能仅向一部分用户暴露新 bundle。在这种环境下，两个加载“相同页面”的人可能实际上运行着不兼容的应用构建。
合成监控在该场景中成为稳定器。它揭示何时 HTML 与 JavaScript 不再匹配，何时边缘节点提供过时的 bundles，何时功能开关以意外组合激活，或何时懒加载模块指向缺失或无效的 chunks。这些并非边缘情况——它们是高频前端开发流程中的常见产物。版本漂移是导致 hydration 失败、路由错误和渲染不一致的最常见原因之一。只有在真实浏览器环境中执行真实应用的合成测试，才能在用户受影响之前持续揭露这些问题。
面向 CSR/SPA/SSR 应用的监控蓝图
面向路由的应用的稳健监控策略不能依赖单一类型的检查。它需要分层。在最高频率层，验证运行时是否启动以及路由器是否正确初始化。在中等频率层，执行关键导航路径并确认核心视图以预期数据渲染。更深层的工作流频率较低，但模拟完整的用户旅程，揭示状态在一系列转场中的行为，而不是孤立屏幕上的表现。
API 监控必须并行存在，因为路由成功只有在底层服务提供一致响应时才成立。资产完整性检查作为补充，确保 bundle、chunk 和 CDN 提供的工件属于同一构建谱系。基于用户画像的测试完善了该蓝图，捕获因认证、角色、地区与功能开关带来的路由差异。组合起来为整个运行时提供了操作可见性，而不仅仅是对首次加载的狭隘视角。
Dotcom-Monitor 如何支持路由感知的监控
由路由驱动的应用需要捕获行为而非标记快照的监控。这是我们在 Dotcom-Monitor 使用的视角。我们的基于浏览器的测试以与用户相同的方式评估应用，跟随路由转场、观察异步数据流并验证组件在 hydration 后变为可交互。由于我们从多个地理位置和设备配置执行测试，我们能发现 CDN 漂移、对网络敏感的路由问题以及只有在多次导航后才出现的细微故障。
我们的工作流脚本模拟经过身份验证和未身份验证路径的真实用户旅程，这使我们能够揭露页面级检查永远检测不到的路由和状态问题。我们关注运行时本身——路由器、数据层和不断演化的 bundle 图——因为这正是定义现代前端可靠性的要素。对于 SPA、CSR、SSR 和混合架构，这种深度可见性现已成为必需，而非可选。
结论：监控运行时，而不是页面
客户端路由已永久改变 Web 的行为。应用在每次导航时不再重启。故障不再以页面破碎的形式出现——而是以行为破碎的形式出现。监控必须发展以应对这一变化。
测量页面加载、静态 DOM 树或服务器响应的工具无法代表现代 SPA、SSR 和混合架构的行为。监控必须跟随路由器、状态层、bundle 图和定义真实用户体验的数据依赖。
监控的未来是运行时感知的。它以行为为导向、由路由驱动、对版本敏感，并深度集成到框架的执行中。那些继续仅监控首屏绘制的组织将拥有“绿色”的仪表盘，而用户却盯着空白面板。
路由框架已将复杂性从服务器迁移到浏览器。监控必须随之移动。