列表页点进详情页时，内容本身往往只改了几块 DOM，视觉上却像整页突然换掉。document.startViewTransition() 可以把这次更新包起来，让浏览器捕捉更新前后的视图，再执行默认的淡入淡出过渡。它不是路由库，也不会替你处理数据请求；真正要做的是把“数据更新”和“动画边界”放在同一个可验证的调用里。

先把视图切换拆成更新和过渡两件事

一个最小列表/详情页面至少有三个状态：当前展示的列表、用户选择的记录、详情内容。不要把请求、模板拼接和动画写成一个无法复用的大函数，先抽出只负责更新界面的 renderView。

const app = document.querySelector('#app');
const back = document.querySelector('#back');

function renderView(view) {
  if (view.type === 'list') {
    app.innerHTML = `
文章列表
      打开第 42 篇`;
    back.hidden = true;
    return;
  }

  app.innerHTML = `
${view.title}
    
这是详情内容。
`;
  back.hidden = false;
}

这里的关键不是示例模板，而是更新函数可以被普通调用，也可以被视图过渡调用。这样做能保证浏览器不支持新 API 时，页面仍有一条确定的工作路径。

用 startViewTransition 包住一次 DOM 更新

在支持 View Transitions API 的浏览器里，把同一个更新回调传给 document.startViewTransition。调用返回的对象可以等待 finished，用于在动画完成后清理临时状态或记录一次交互结果。

function updateView(view) {
  const update = () => renderView(view);

  if (typeof document.startViewTransition === 'function') {
    const transition = document.startViewTransition(update);
    transition.finished.catch(() => {
      // 过渡被跳过时，不影响页面已经完成的更新
    });
    return transition;
  }

  update();
  return null;
}

document.addEventListener('click', (event) => {
  const button = event.target.closest('[data-id]');
  if (button) updateView({ type: 'detail', title: '第 42 篇文章' });
});

back.addEventListener('click', () => updateView({ type: 'list' }));

别把更新回调写成只返回 Promise 的异步大段逻辑。数据请求可以先完成，再把已准备好的视图更新交给过渡；如果必须在回调内等待，仍要观察失败和过渡被跳过的情况，不能把动画完成当成业务请求成功。

默认动画够用时，只给关键元素命名

默认过渡已经能表达页面内容变化。需要让标题或封面形成连续感时，再给确实对应的元素设置 view-transition-name。名称必须在同一时刻保持唯一，否则容易得到难以解释的配对结果。

@media (prefers-reduced-motion: no-preference) {
  .article-title {
    view-transition-name: article-title;
  }
}

::view-transition-old(root),
::view-transition-new(root) {
  animation-duration: 180ms;
  animation-timing-function: ease-out;
}

把时长控制在很短的范围，通常比堆叠多个旋转、缩放和延迟更稳。对于阅读页面，标题位置连续、内容及时出现，比“动画很丰富”更重要。

回退路径要和新 API 共用同一份更新函数

兼容处理最容易写成两套逻辑：新浏览器走动画分支，旧浏览器走另一套模板。更可靠的方式是只区分“是否包装更新”，不复制视图渲染。

@media (prefers-reduced-motion: reduce) {
  ::view-transition-group(*) {
    animation-duration: 1ms;
  }
}

媒体查询只负责表达用户的动画偏好，数据请求的错误状态仍由 JavaScript 渲染。测试时分别关闭脚本能力、打开减少动画设置，并在网络失败时点击一次入口，三种场景都应能看到明确结果。

上线前用四个状态验收，而不是只看一次动效

开发者工具里看到过渡动画，并不代表交互完成。至少检查列表进入详情、详情返回列表、请求失败、重复点击这四种状态。重复点击尤其容易暴露问题：如果每次点击都发起一次请求或覆盖当前视图，动画再顺滑也掩盖不了状态竞争。

• 正常切换：旧内容消失后，新标题和返回按钮同时出现。
• 不支持 API：去掉能力分支后仍能进入详情，不出现空白主区域。
• 减少动画：内容立即更新，焦点和键盘操作不被动画延迟。
• 失败恢复：请求失败时显示错误提示，并允许回到列表重新尝试。

常见问题

View Transitions API 能替代前端路由吗？

不能。它只处理视图状态之间的过渡，路由、历史记录、数据请求和权限判断仍由应用负责。

不支持 startViewTransition 的浏览器会白屏吗？

只要保留直接调用更新函数的回退分支，就不会因为缺少该 API 而白屏；页面会少一段动画，但功能仍应完成。

为什么命名元素后动画变得奇怪？

常见原因是同一个名称同时出现在多个元素上，或新旧视图的命名元素结构不一致。先移除命名规则确认默认过渡，再一次只添加一个唯一名称。

应该把过渡时长设置得很长吗？

不建议。内容型页面一般使用短时长并尊重减少动画偏好，重点是让用户确认状态变化，而不是等待动画结束。

迁移清单

如果现有项目已经有列表和详情渲染逻辑，可以先把 DOM 更新收敛到一个函数，再加能力检测和过渡包装；最后补上减少动画、失败状态和重复点击测试。做到这三层，View Transitions API 才是渐进增强，而不是新浏览器专属的入口。