View Transition API 实战：筛选列表切换不再硬跳，兼容回退这样落地

筛选商品时，页面从「全部」切到「仅看现货」，列表会整块重绘。数据明明只换了一批卡片，用户却像被突然带到了另一个页面。View Transition API 很适合处理这类同页状态切换：浏览器先保留旧视图快照，再在下一帧展示更新后的 DOM；不支持它的浏览器则照常更新列表，不会把核心功能绑定在动画是否生效上。

View Transition API 为什么适合筛选列表

这项能力处理的是「同一次状态切换前后，页面视觉该如何衔接」。它不是列表组件，也不会替你发起接口请求。以电商后台的库存筛选为例，接口返回的数据、当前筛选条件和分页游标仍由现有状态管理逻辑负责；API 只包住最后那一步 renderProducts()。

这样拆分有一个实际好处：请求慢的时候依旧可以正常显示 loading 状态，拿到结果后才启动视觉过渡。不用把网络请求塞进 API 回调里，回调返回的 Promise 没结束，过渡也会一直等待，用户看到的往往是一段没有必要的长时间停顿。

最小接入：把渲染动作放进 update 回调

下面的例子保留了普通渲染函数。支持 API 时，浏览器在 applyProducts 之前截取旧视图快照；函数执行完成后，新卡片内容进入下一帧渲染。没有 API 时，代码直接执行渲染，筛选结果返回不会被任何逻辑阻塞。

let currentFilter = "all";

function applyProducts(products, filter) {
  currentFilter = filter;
  productList.replaceChildren(
    ...products.map((item) => createProductCard(item))
  );
}

function showProducts(products, filter) {
  const update = () => applyProducts(products, filter);

  if (!document.startViewTransition) {
    update();
    return;
  }

  document.startViewTransition(update);
}

这里的 update 要尽量精简，只做同步的 DOM 切换操作。图片预加载、埋点上报、二次查询这类工作都放到回调外面处理。页面里如果有多个筛选按钮，还要在请求回来时核对当前生效的筛选值；否则用户连续点「现货」「促销」，先返回的旧响应仍可能把后一个筛选的正确结果覆盖掉。

给过渡一个克制的默认样式

默认动画已经可以正常工作，但列表更新场景更适合短时长的淡入淡出效果。把动画时长控制在 180ms 到 260ms 区间，既能让用户感知到状态发生了变化，又不会拖慢高频次的筛选操作。

::view-transition-old(root) {
  animation: 180ms ease-out both fade-out;
}

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

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

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

如果只想让单张商品主图平滑移动切换，而不是整个根节点一起淡入淡出，再给卡片里的图片单独配置 view-transition-name。同一时间页面里的过渡名称必须唯一；把每个商品都写成固定的 product-image，很容易出现快照冲突的问题。列表动态增减幅度大的时候，先从根节点级别的过渡开始尝试会更稳妥。

请求竞态与动效要分开处理

真实页面落地时最容易踩的坑是：过渡视觉看起来很流畅，最终展示的数据却是错的。比如「全部」筛选请求晚到，「现货」筛选请求先返回，最后一次渲染反而显示了全部商品。给请求递增序号做标记，只有序号仍是最新的那次请求结果才会进入 showProducts。

let latestRequest = 0;

async function changeFilter(filter) {
  const requestId = ++latestRequest;
  setFilterPending(true);

  try {
    const products = await fetchProducts({ filter });
    if (requestId !== latestRequest) return;
    showProducts(products, filter);
  } finally {
    if (requestId === latestRequest) setFilterPending(false);
  }
}

这段逻辑的重点不在炫技。先保证数据完全正确，再让视觉层处理「旧状态离场、新状态进入」的效果。动画本身无法修复竞态问题，也不该掩盖空列表、接口失败和权限不足等业务异常状态；这些状态仍应在真实列表区域清晰呈现给用户。

和手写双列表方案相比，少了哪些负担

过去要实现同样的效果，常见做法是把旧列表留在页面上，再叠放一份新列表，用绝对定位和类名切换做出交叠效果。它能完成视觉需求，但后续要维护的细节很多：旧节点何时销毁、两个列表会不会重复响应点击、焦点应该留在哪个列表上、读屏软件会不会读到两次相同内容，都需要额外做兼容处理。

不是每个列表都要加过渡效果。输入框联想、滚动加载、每秒多次刷新的监控表格场景里，动效可能比内容本身更抢眼。不用急着套 API，先确认一次切换操作是否对应用户认知里的「场景变化」；有这个明确的变化预期，再加过渡才有实际价值。

上线前检查：兼容、焦点和降低动态效果适配

• 在不支持 document.startViewTransition 的环境确认列表仍能立即更新。
• 连续切换三个以上筛选项，确认旧请求不会覆盖最新返回结果。
• 用键盘操作筛选按钮后，确认焦点没有跳到被替换的卡片或者页面顶部。
• 为 prefers-reduced-motion 准备更短或者无动画的样式，避免触发用户设备的强制位移动画限制。
• 在低端设备上检查大图列表场景；如果出现掉帧，缩短动画时长或者只对关键区域单独命名过渡。

@media (prefers-reduced-motion: reduce) {
  ::view-transition-old(root),
  ::view-transition-new(root) {
    animation-duration: 1ms;
  }
}

MDN 将 document.startViewTransition() 标注为较新的跨浏览器可用能力，但旧设备与旧浏览器仍可能缺少原生支持。把特性检测逻辑写在业务入口处，能让这次接入是一层体验增益，而不是新的兼容性门槛。

相关问题

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

不能。路由负责 URL 管理、数据加载和页面全局状态，API 只负责在视图前后状态之间建立过渡效果。

回调里可以放异步请求吗？

可以返回 Promise，但筛选列表场景通常不建议这样做。先完成请求再更新 DOM，能避免过渡长时间占住页面。

不支持的浏览器会报错吗？

只要先判断 document.startViewTransition 是否存在，就能回退到普通渲染逻辑，完全不会影响正常筛选功能。

每个卡片都要设置 view-transition-name 吗？

不必。先从根节点级别的过渡开始尝试；只有明确需要把同一元素从旧位置平滑带到新位置时，才为少量关键元素设置唯一名称。

收尾

筛选列表的体验提升，关键不是多一段动画，而是把「数据已换、页面也该连续地展示切换过程」这件事交给浏览器原生处理。保持渲染函数简单、把请求竞态逻辑留在数据层、把回退路径写在入口处，这套接入方式放到现有 SPA 里通常不会牵动原有大结构。