${item.title}
${item.price}
${item.text}
商品列表点进详情页时,内容加载本身没有变慢,用户却会因为整页突然闪白而丢失位置感。现在可以先用 CSS View Transitions API 给这类切换加一层浏览器原生过渡:同文档场景由 document.startViewTransition() 包住 DOM 更新,不支持该 API 的浏览器则直接走原来的更新逻辑。
document.startViewTransition(update) 包住状态更新,最小改动就能看到过渡效果。view-transition-name,名称必须在当前快照中唯一。传统页面切换通常只有两个状态:旧 DOM 直接消失,新 DOM 直接出现。即便接口只用了几十毫秒,布局也会重新全量计算,用户看到的还是一次突兀的“清空—重画”过程。View Transitions API 会先捕获旧视图状态,再执行更新回调,最后让新旧两张快照通过 CSS 动画完成平滑交接。
它不是路由库,也不负责请求数据。它只接管“状态已经准备好切换时,旧视图如何过渡到新视图”这一小段时间的逻辑。这个边界非常清晰:数据加载、错误提示和路由历史仍可以完全沿用现有代码负责。
假设页面只有一个 main#app,点击卡片后用本地内存数据替换页面内容。先把原来写好的更新函数保留为唯一的事实来源:
const products = {
keyboard: { title: '静音机械键盘', price: '¥299', text: '适合夜间写代码。' },
lamp: { title: '桌面阅读灯', price: '¥159', text: '支持三档色温。' }
};
function renderProduct(key) {
const item = products[key];
document.querySelector('#app').innerHTML = `
返回列表
${item.title}
${item.price}
${item.text}
`;
}
function changeView(update) {
if (!document.startViewTransition) {
update();
return;
}
document.startViewTransition(update);
}
document.addEventListener('click', (event) => {
const link = event.target.closest('[data-product]');
if (!link) return;
event.preventDefault();
const key = link.dataset.product;
changeView(() => renderProduct(key));
});
调整的逻辑只有一个:把页面更新函数作为回调传给 startViewTransition。如果浏览器没有这个方法,changeView 仍然会调用 update(),所以原有功能不会被动画逻辑绑架。

默认情况下,浏览器会把整个根视图做淡入淡出效果。要让列表里的商品图像“连贯滑动”到详情页,需要给新旧页面对应的元素设置完全相同的名称:
/* 列表和详情中的商品图都使用同一个名称 */
.product-image {
view-transition-name: product-image;
}
::view-transition-old(product-image) {
animation: image-out 180ms ease both;
}
::view-transition-new(product-image) {
animation: image-in 220ms ease both;
}
@keyframes image-out {
to { opacity: 0; transform: scale(.96); }
}
@keyframes image-in {
from { opacity: 0; transform: scale(1.04); }
}
这里不要给每张列表图片都写同一个名称。如果同一份快照里出现两个相同的 view-transition-name,浏览器无法判断它们的对应关系。只需要给要做连续移动的主图单独命名,其他普通缩略图保持默认即可。
默认过渡已经能正常使用,但后台管理页、商品页和文档页的交互节奏并不一样。可以先只调整根视图的动画持续时间,再按需要覆盖单个命名元素的动画参数:
::view-transition-group(root) {
animation-duration: 160ms;
}
@media (prefers-reduced-motion: reduce) {
::view-transition-group(root),
::view-transition-old(product-image),
::view-transition-new(product-image) {
animation-duration: 1ms;
}
}
动画时长越短不一定体验越好。列表跳转到详情通常 160—240ms 已经足够,超过 400ms 就容易让用户感觉点击没有响应。系统层面的减少动效偏好也要尊重:这时保留状态切换逻辑,直接缩短动画时间或者完全关闭过渡即可。
手写过渡方案往往要同时维护旧节点、克隆节点、绝对定位状态和清理时机;一旦新内容高度出现变化,遮罩层和滚动位置就容易出现各种边界问题。View Transitions API 把快照生成和伪元素树管理交给浏览器处理,代码逻辑更贴近“更新状态”本身,不需要额外维护多余的过渡相关变量。
| 场景 | 推荐做法 | 要检查的边界 |
|---|---|---|
| SPA 局部 DOM 更新 | 调用 startViewTransition | 更新回调必须能正常完成且不抛出错误 |
| 商品图或头像连续移动 | 设置唯一 view-transition-name | 同一快照内不能出现重名 |
| 多页面同源跳转 | 使用跨文档过渡规则 | 不能直接照搬 SPA 的手动调用逻辑 |
| 旧浏览器或减少动效模式 | 直接更新或设置极短动画 | 核心内容展示不能依赖过渡完成 |

如果点击后还要请求详情数据,先处理好加载、失败和取消逻辑,再决定何时启动视图过渡。更新回调抛出错误会直接让过渡失败;更稳妥的做法是等可渲染的状态准备完成,出现失败情况时直接保留当前页面或者展示明确的错误区域即可。
视图过渡只能让变化更容易被用户感知,不能修复错误的滚动恢复、重复请求和焦点丢失问题。详情页完全展示出来后,要把键盘焦点放到新标题或者返回链接,返回列表时也要根据业务需要决定是否恢复原滚动位置。
MDN 当前将核心方法标为 Baseline 2025,但部分成员和跨文档能力的兼容覆盖范围仍可能有差异。发布前至少在目标浏览器上验证几个核心点:支持 API 时有正常过渡、不支持时能正常更新内容、开启减少动效时不会出现闪烁、更新失败时不会卡在旧快照页面。
不是。它是标准浏览器 API,无框架页面直接调用 document.startViewTransition 即可;React、Vue 只是把回调接到自己的状态更新流程中做适配而已。
只要保留能力检测逻辑,不支持时直接执行原有的更新函数,就不会因为动画缺失出现白屏。降级版本虽然没有过渡效果,但仍要完整完成路由跳转、内容渲染和焦点处理逻辑。
先检查新旧元素是否真的同时出现在前后两张快照中,再检查名称是否唯一、元素是否被条件渲染提前移除,以及自定义伪元素选择器是否书写正确。
跨文档过渡依赖同源导航和对应的 CSS 配置,不能直接把 SPA 的调用逻辑复制到链接点击事件里。两种场景要分别做兼容测试。
给页面加 View Transitions API,最小改动不是重写整个路由逻辑,而是把已有的 DOM 更新包进一个可选的过渡入口。先让无动画路径完整可用,再为少数关键元素添加唯一名称,最后用浏览器能力和用户动效偏好做降级判断,这样动画只是体验加分项,不会变成影响核心功能的单点故障。
Go rows.Next 返回 false 不一定是查完:Err、Close 和扫描失败怎么定位