浏览器 View Transition 的跨文档能力值得关注，核心原因不是“页面会自动变得更炫”，而是传统多页应用终于有了一条浏览器原生的连续过渡路径：列表页点击链接进入详情页时，两个独立 HTML 文档可以在同源条件下交接视觉状态。对仍然依赖服务端渲染、静态生成或渐进式增强的网站来说，这比为了一个转场效果改造成 SPA 更轻量。

它目前仍然是渐进增强能力。最小用法只需要让当前页和目标页都加入 CSS 选择加入；浏览器支持时显示过渡，不支持时仍然走普通链接导航。下面用一个“文章列表页 → 文章详情页”的小项目，说明它为什么值得纳入前端架构判断。

它解决的是 MPA 的连续感问题

SPA 可以在同一个文档里调用 document.startViewTransition()，把 DOM 更新包进一次过渡；MPA 则是点击链接后离开旧文档、加载新文档。跨文档能力把这两页之间的快照和 CSS 动画交给浏览器协调，因此开发者不需要拦截链接、手写全局路由，也不必把整个站点迁移成客户端渲染。

官方资料给出的边界很清楚：参与导航的两个文档必须同源，并且两边都要选择加入。这里的“同源”由协议、主机名和端口共同决定；同站但不同源的跳转不能直接获得这种跨文档过渡。

官方资料：https://developer.chrome.com/docs/web-platform/view-transitions/cross-document

规范参考：https://developer.mozilla.org/en-US/docs/Web/API/View_Transition_API

先用最小 CSS 让两个页面具备资格

假设项目有 index.html 和 detail.html，两页都加载同一份 site.css。最小配置只有一个 at-rule：

/* 两个同源文档都要加载这段 CSS，浏览器才会尝试建立跨文档过渡。 */
@view-transition {
  navigation: auto;
}

/* 没有命名元素时，先使用根页面的默认淡入淡出。 */
::view-transition-old(root) {
  animation: 180ms ease-out both page-out;
}

::view-transition-new(root) {
  animation: 220ms ease-in both page-in;
}

@keyframes page-out {
  to {
    opacity: 0;
    transform: translateY(-6px);
  }
}

@keyframes page-in {
  from {
    opacity: 0;
    transform: translateY(6px);
  }
}

这里不需要写 JavaScript 启动函数，也不需要把链接改成按钮。用户通过页面内容发起同源导航时，浏览器才会尝试使用过渡；地址栏、书签或重新加载等场景不应被当成业务流程的一部分。

一个常见错误是只在列表页加配置，详情页忘了同步。跨文档过渡不是单页脚本注入，当前文档和目标文档都必须明确选择加入。

用稳定名称让卡片“接”到详情标题

默认的根页面过渡只能表达整页切换。如果希望列表中的封面或标题自然地接到详情页对应元素，就让两页中代表同一内容的元素使用相同的 view-transition-name。名称必须在同一时刻对应唯一元素，不能把同一个名称批量分配给整张列表卡片。

  
跨文档页面过渡



跨文档页面过渡

实际项目更适合把名称写入 CSS 类或由模板输出，避免把内容 ID 直接散落在 HTML。命名元素的目的是告诉浏览器“这是同一件视觉对象”，不是把数据库主键暴露给用户。

什么时候需要 pageswap 和 pagereveal

只想要默认过渡时，到上一步就够了。需要根据前进/后退方向选择动画，或在截图生成前临时决定哪个元素参与时，可以使用跨文档导航相关事件：

• pageswap 在旧页面即将离开、旧页面最后一帧生成前触发，适合准备离开页的临时状态。
• pagereveal 在新页面初始化后、第一次渲染机会前触发，适合根据导航信息设置新页面的过渡类型。

事件对每次同源跨文档导航都可能触发，但只有本次确实建立了视图过渡时，事件对象上的 viewTransition 才有可操作的过渡对象。下面的代码只演示判断边界，不把动画当成数据传递通道：

// 新页面在首次绘制前读取过渡对象；不支持或未建立过渡时直接返回。
window.addEventListener('pagereveal', (event) => {
  if (!event.viewTransition) return;

  // 只给需要特殊动效的页面加类型，避免所有页面共享同一种动画。
  const isDetailPage = document.body.dataset.page === 'detail';
  if (isDetailPage && event.viewTransition.types) {
    event.viewTransition.types.add('detail-enter');
  }
});

// 旧页面只保存可恢复的轻量状态，不保存敏感信息或大对象。
window.addEventListener('pageswap', (event) => {
  if (!event.viewTransition) return;
  sessionStorage.setItem('last-page-kind', document.body.dataset.page || 'unknown');
});

如果只是想分别处理前进和后退，优先使用官方支持的过渡类型和 CSS 选择器；不要为了动画拦截所有链接，也不要把 sessionStorage 当成跨站通信手段。

为什么现在值得关注，而不是马上重写成 SPA

第一，它把“页面切换连续感”和“应用架构”拆开了。服务端渲染、静态站点、多页电商和内容站可以先改善关键链路，不必因为动画需求引入新的路由、状态管理和首屏数据协议。

第二，它使用 CSS 和浏览器生命周期，维护面比一套自定义页面切换框架小。默认路径没有额外的启动 API，命名元素和事件定制也可以按页面逐步加入，适合渐进式改造。

第三，它迫使团队重新审视页面边界：哪些元素代表同一个内容对象，哪些状态必须在新文档中恢复，哪些导航应该保持朴素。这些判断对性能、可访问性和缓存策略都有帮助。

上线前要把兼容性和可访问性放在动画前面

Chrome 官方文档指出，跨文档 View Transition 从 Chrome 126 开始支持；MDN 对 @view-transition 仍标注为 Limited availability。具体项目还要按目标浏览器矩阵重新确认，不能把某个浏览器版本直接等同于全端可用。

最稳妥的上线策略是把它当作增强层：普通链接导航必须完整可用，过渡被跳过时内容、焦点和返回行为不能改变。对于偏好减少动态效果的用户，也应关闭或缩短自定义动画：

/* 尊重用户的减少动态效果偏好，保留页面切换本身。 */
@media (prefers-reduced-motion: reduce) {
  ::view-transition-old(root),
  ::view-transition-new(root) {
    animation-duration: 1ms;
  }
}

还要特别留意焦点位置、标题朗读和加载较慢时的等待体验。View Transition 只负责视觉交接，不会替你修复页面语义、表单状态或错误恢复。

结论：它的价值在于降低 MPA 改善体验的门槛

跨文档 View Transition 的真正变化，是让多页站点可以用很小的 CSS 入口获得浏览器协调的页面过渡，同时保留原有的链接导航和服务端页面边界。最小项目从两页同源文档和一份共享 CSS 开始，再按需要添加命名元素、pageswap、pagereveal 与过渡类型。

如果团队当前的问题是“MPA 页面之间太割裂”，它值得先做一条小链路试用；如果问题是数据协议、首屏性能或交互状态管理，不能把转场能力当成架构升级的替代品。

相关问题

跨文档 View Transition 是否必须使用 JavaScript？

不必须。最小跨文档过渡由两页的 @view-transition CSS 选择加入和同源导航触发；只有需要动态命名、方向或类型时才增加 JavaScript。

不同子域名之间能否直接过渡？

不能把“同站”当成“同源”。协议、主机名或端口不同，都需要先按浏览器同源规则判断；跨文档 View Transition 的基础条件是参与导航的文档同源。

不支持的浏览器会不会打不开页面？

正常降级时不会。它应该是可选的视觉层，普通链接、页面内容和返回行为都要独立成立。