动画库配了三年，今天才发现切页这件事根本不用靠 Framer Motion——View Transitions API 把这件事彻底变了

动画库配了三年，今天才发现切页这件事根本不用靠 Framer Motion——View Transitions API 把这件事彻底变了

切页动画这件事，团队通常的第一反应是装 Framer Motion 或者 GSAP。2026 年的今天，浏览器已经自己会了，而且装进去的代码比动画库少几个数量级。

一个案例说清楚这个变化。去年 Q2，Mintec 帮一个媒体作品集网站做重构。原来用 Framer Motion（52KB）+ Barba.js（28KB）+ GSAP ScrollTrigger（32KB），动画相关 JS 总共 112KB 压缩后。换成 View Transitions API + CSS scroll-driven animations + Speculation Rules API 之后，动画相关 JS 变成 0KB。INP 改善了 18%，低端 Android 机上的帧率从跳帧变成了稳定 60fps。

实际怎么用

MPA（多页面应用）最简单，连 JS 都不用写。只需要在两边的 CSS 里各加一行：

@view-transition {
  navigation: auto;
}

点链接、点返回，浏览器自动给你加crossfade。不用拦link事件，不用管history stack，CSS自己认得「这是导航」。

SPA 稍微多一步，需要在切换视图的回调外层包一层：

function navigateTo(path) {
  if (!document.startViewTransition) {
    // 旧浏览器直接切
    renderView(path);
    return;
  }
  document.startViewTransition(() => {
    renderView(path);
  });
}

同样旧浏览器直接走else，View Transitions 是渐进增强，不是破坏性升级。

真正值回票价的是 shared element transition。给新旧两个页面的同一个元素取同一个名字，浏览器自己会把它从A位置的形态morph成B位置的形态：

/* 列表页的卡片图 */
.product-card img {
  view-transition-name: product-hero;
}

/* 详情页的大图 */
.product-detail img {
  view-transition-name: product-hero;
}

以前用 Framer Motion 要写 LayoutGroup + AnimatePresence + shared layout ID，现在5行CSS。

什么场景不用换

手淘拖拽、pinchzoom、弹簧物理这类手势驱动的交互动画，View Transitions 目前没有对应的原生能力。这类场景 Framer Motion 仍然是正确答案。

同样的，动画中途可以被用户操作重新定位（比如列表拖拽排序）、或者需要在多个独立时间线上协调复杂编排，原生API管不了。View Transitions 的定位是「浏览器帮你做，不需要你来管」的场景；对于「我要精确控制每一帧」的场景，库仍然是工具。

怎么判断该不该换

有一个实用的筛选条件：你的动画是不是「因为导航/状态切换触发的，且不需要手势打断的」？

如果是，View Transitions 大概率够用。如果不是（比如拖放、physics模拟、复杂交错时序），留着 Framer Motion。

实际上大多数团队的结果是混合：路由层用 View Transitions（省bundle），交互层保留 Framer Motion（管手势和复杂编排）。把动画库从全局依赖变成按需引入，本身就是收益。

下一步你可以做的：找一个页面的视图切换逻辑，用 5 行 JS 包装 document.startViewTransition()，对比一下视觉和性能指标。