浏览器 View Transitions API 怎么处理列表增删：跨页面动画与无障碍降级

做列表新增、删除操作的时候，直接修改DOM经常会导致其余卡片突兀跳位。用View Transitions API把这次DOM更新逻辑包裹起来，浏览器会自动为更新前后的视图生成过渡动画；不支持该API的浏览器可以直接走原有更新逻辑，系统开启「减少动态效果」的用户也会自动跳过动画。

这类动画的关键不是把每个卡片都做成复杂时间线，而是把“状态更新”和“动画增强”分开：先保证列表正确，再让支持的浏览器平滑呈现位置变化。

先分清：列表动画和跨页面过渡不是一回事

这篇讨论的是同一文档内的列表变化：点击“新增”、删除一行、切换筛选条件，数据和 DOM 仍在当前页面完成更新。Chrome 的同文档示例也是通过 document.startViewTransition(update) 包住这类 DOM 变化；它不是某个框架专属能力。

跨页面导航对应的是跨文档 View Transition，要求同源页面双方都开启支持，触发逻辑和兼容边界和单文档模式差别很大。很多人在SPA项目里混写两种模式，误以为点一下链接就能自动触发过渡动画，很容易踩坑。

最小实现：把一次列表更新放进过渡边界

先抽一个专门负责把数据映射到DOM的独立函数，这个函数完全不涉及动画逻辑，就算浏览器没有对应API，也能直接调用正常完成操作。

function renderItems(items) {
  list.replaceChildren(...items.map(item => {
    const li = document.createElement('li');
    li.dataset.itemId = item.id;
    li.textContent = item.title;
    return li;
  }));
}

function updateList(items) {
  if (!document.startViewTransition) {
    renderItems(items);
    return;
  }

  document.startViewTransition(() => renderItems(items));
}

这里的回退逻辑优先级很高：动画属于体验增强层，绝对不能变成增删功能的前置依赖。更新函数也不要在过渡回调外面提前改一次DOM，不然浏览器拿到的「旧状态」早就不是用户当前可见的视图状态，动画逻辑直接就乱了。

新增、删除、筛选分别怎么选动画范围

新增一项：让稳定身份的卡片继续做位置过渡

新增后，旧卡片会移动到新位置。默认过渡已经能处理整体视图变化；如果希望某一张卡片拥有独立动画，再为它设置稳定的 view-transition-name，值应来自业务 ID，而不是数组下标。

删除一项：先处理焦点，再更新 DOM

如果点击删除按钮时这个按钮正处于焦点状态，被删的节点销毁后，键盘操作的用户焦点会直接跳回页面顶部，打断操作流程。可以在删除操作触发前先记录目标节点后面的下一个可聚焦元素，DOM更新完成后把焦点转移到还存在的相邻按钮上，同时配上可见的状态提示告知用户删除结果。

function removeItem(id) {
  const current = document.activeElement;
  const next = current?.closest('[data-item-id]')?.nextElementSibling;
  const commit = () => {
    items = items.filter(item => item.id !== id);
    renderItems(items);
  };
  const transition = document.startViewTransition
    ? document.startViewTransition(commit)
    : null;
  transition?.finished.then(() => (next?.querySelector('button') || list).focus());
}

生产环境的代码还要额外判断目标节点是否还存在于文档树里，如果删的是列表最后一项，就把焦点落到列表容器或者新增按钮上，不要去操作已经脱离DOM的无效节点。

筛选列表：避免给每个结果硬编码动画名

筛选操作往往会同时调整大量项的位置，优先用默认的视图快照过渡就好。只有产品确实需要单个实体跟随移动的效果时，再给稳定的业务实体配置独立的view-transition-name；如果过滤结果变动非常频繁，乱给元素加命名反而会让调试成本比做动画本身还高。

比较三种方案：默认过渡、命名元素与普通 CSS

如果只是要改按钮颜色、元素高度这类单属性变化，用普通CSS transition实现起来更直接；如果是多张卡片随排序整体换位的场景，用View Transition能省下大量状态同步的维护成本。没必要为了强行用上新API，把所有微交互都套进页面级过渡的逻辑里。

减少动态效果与失败回退要一起验收

动画不是所有人的默认偏好。针对 prefers-reduced-motion: reduce，可以把过渡时长改为极短，或者直接隐藏 View Transition 的伪元素动画：

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

测试时至少覆盖三条路径：不支持 document.startViewTransition 的浏览器、支持 API 但更新回调抛错的情况、系统开启减少动态效果的情况。API 的 updateCallbackDone 只代表 DOM 更新回调完成，不等于视觉动画已经结束；需要等待整段动画时再观察 finished。

常见问题

View Transitions API 会替代前端框架的列表渲染吗？

不会。框架本身还是负责状态管理和DOM渲染，这个API只用来包裹单次视图变化的过程，把它当成渐进增强层来用，同一套状态逻辑可以在不支持API的浏览器里正常运行。

删除列表项后为什么焦点跑了？

核心原因是原来的焦点节点已经随删除操作被移除了。只要在删除前提前存好相邻的可聚焦目标，DOM更新完成后把焦点移到下一个可操作的元素上，找不到有效目标时就把焦点放回列表容器或者新增按钮即可。

为什么不直接给每个 li 写一个动画？

列表排序和筛选操作会批量改动节点集合，要是给每一项单独维护动画状态，很容易和数据状态出现不同步的问题。先用默认过渡跑通体验验证效果，确认真的需要实体跟随移动的效果时，再给稳定的业务实体加命名配置。

验收清单

• 关闭 JavaScript 动画增强后，新增、删除和筛选仍能正确完成。
• 同一文档更新只调用一次过渡包装，更新回调不会重复提交状态。
• 删除当前焦点项后，焦点落在可见且可操作的目标上。
• 开启减少动态效果后，页面没有长时间位移或闪烁。
• 用浏览器开发者工具检查旧状态、新状态和实际动画时序，再决定是否需要命名元素。