大概半年多前，我接手一个靠window.addEventListener('scroll', ...)做了三套视差的页面：背景云层、标题上浮、卡片旋转。用户换了新手机后第一个反馈就是“滚动像打字机”，我在第二天把所有 scroll 监听拆掉了，换成 CSS Scroll-Driven Animations 的scroll()时间线。如果你也想告别 JS 监听 scroll，把视差做成真正“不占主线程”的高性能效果，这篇文章应该能帮你少踩不少坑。
先说一下为什么这个方向值得投入。Scroll-Driven Animations 的核心思路是：把滚动位置当成一条“时间线”，让 CSS 动画直接由它驱动。以前我们要手动监听滚动事件，把滚动距离换算成百分比，再用requestAnimationFrame去改样式；现在只需要声明animation-timeline: scroll()，告诉浏览器“动画沿着哪个滚动容器的时间线走”，剩下的事情全部交给合成器。降下去了主线程的计算压力，也摆脱了“每帧都在算 offsetTop”的尴尬处境。
这个能力的适用面比大多数人想象得广：视差只是它最出圈的场景，滚动进度条、卡片入场、下拉后导航栏变色、长页面中图标的“惰性移动”都能用它做。适合谁看？正在被 ScrollTrigger、skrollr 或手写 scroll 监听折磨的前端，以及想把动效做轻一点的交互设计师。我默认你懂基本 CSS 动画语法，但不会默认你背过 ScrollTimeline 规范——下面所有名词我都会从“为什么”开始解释。
1. 一个 Scroll 监听者的“中年危机”：为什么说 JS 做视差越来越吃力
1.1 那些年我们用 JS scroll 监听做的事
早几年做视差，业界标准动作是：
window.addEventListener('scroll', () => { const y = window.scrollY; const translateY = y * 0.4; $('.parallax-bg').style.transform = `translate3d(0, ${translateY}px, 0)`; });简单吧？但在真实项目里，一套像样的视差页面往往同时存在七八个这样的监听，每个监听里还要加节流、防抖、requestAnimationFrame锁，甚至要手动处理滚动容器不是window的情况。我见过一个活动页，滚动一帧里要读offsetTop、getBoundingClientRect()、offsetHeight，然后算三个层的位移，最后再写transform。这套组合拳打下来，页面在低端安卓机上基本就是幻灯片。
当时大家也知道性能有坑，所以常用rAF把逻辑锁进下一帧：
let ticking = false; window.addEventListener('scroll', () => { if (!ticking) { window.requestAnimationFrame(() => { updateParallax(); // 内部还要读布局 ticking = false; }); ticking = true; } });这个方案解决了一部分“重复计算”的问题，但没有解决本质问题：只要回调还在主线程跑，滚动输入与页面绘制之间的每一帧，都可能被其他 JS 任务抢走。另外，读offsetTop、getBoundingClientRect()这类属性会强制浏览器执行同步布局，如果紧跟着又写样式，就触发了 layout thrashing——页面越复杂，这一来一回越贵。
1.2 主线程负担和“看起来卡”的真相
很多人把卡顿归咎于“帧数不够 60fps”，其实视差卡顿的根源更微妙：浏览器的主线程既要处理滚动输入、JS 回调、样式计算，又要处理布局和绘制指令。只要你的 scroll 回调里塞了“读布局→改样式”这样的操作，浏览器就可能在每一帧里被迫多次重排。
我做过一个很粗糙的对照实验：同样一个 100vh 高的背景层，用 JS 监听 scroll 改translateY，和用 CSSscroll()时间线改translateY，在 Chrome Performance 面板里录制 2 秒快速滚动。JS 方案不断出现长任务和紫色脚本块；CSS 方案几乎只有合成器的提交记录。差距看起来很玄幻，其实原理很直接：Scroll-Driven Animations 把“滚动位置 → 动画进度”的换算放进了浏览器内部，而且动画可以只操作 transform/opacity 这类不会触发布局的属性。
这还没算代码层面的人为损耗。手写监听经常会出现防抖时间设置不对、滚动容器判断错、resize 后没有重新计算等边界问题，而这些在“声明式”方案里都不存在。
1.3 为什么我不能继续“修修补补”
我也不是没用过现成的 JS 库。GSAP 的 ScrollTrigger 做得确实好，但它体积不小；为了一个视差效果引入一个小型渲染引擎，对小项目来说像大炮打蚊子。更关键的是，团队合作时，JS 监听方案非常容易写出“孤儿代码”：页面结构改了，滚动容器从window换成了某个div，回调逻辑立刻失效。CSS 方案里，scroll()的值是基于滚动父级的相对关系，结构一变，只要选择器还在，行为基本不变。这才是我“告别 JS 监听 scroll”的决定性理由——不是我有仓库洁癖，是 JS 方案的维护成本太高了。
2. 理解 Scroll-Driven Animations 的关键语法：scroll() 与 view-timeline
2.1 先理解“时间线”这个抽象概念
普通 CSS 动画默认时间线是“文档时间”：动画从 0s 开始，到 1s、2s，进度由真实时间决定。Scroll-Driven Animations 则把时间线换成了“滚动进度”：滚动容器从顶部滚到底部，对应动画从 0% 到 100%。你可以把它想象成看电影和手动拖进度条：普通动画是自动播放，滚动驱动动画是“拖到哪，播到哪”。
最直接的入口是animation-timeline属性。给某个元素设置animation-timeline: scroll(root)，再给它声明@keyframes，浏览器就会把这个元素的动画进度绑定到页面滚动进度上。
.parallax-bg { animation: moveBg 1s linear both; animation-timeline: scroll(root); } @keyframes moveBg { from { transform: translate3d(0, 0, 0); } to { transform: translate3d(0, -20vh, 0); } }注意我这里故意写了animation: moveBg 1s linear both，其中1s在 Scroll-Driven Animations 里其实不再有意义，被时间线直接覆盖。真正驱动动画的是animation-timeline。
2.2 scroll() 里那个 block nearest 到底是什么意思
scroll()函数的完整形态长这样：
animation-timeline: scroll(<scroller> <axis>);参数有两个部分：
<scroller>：指定哪个滚动容器。取值是nearest、root、self。nearest表示“最近的、可滚动的祖先元素”；root表示文档根滚动区域，通常就是页面；self表示元素自己滚动。<axis>：指定沿哪个轴滚动。取值block、inline、x、y。默认是block，在横排书写模式下就是竖直方向。
所以animation-timeline: scroll(block nearest)是我最常写的组合：找到最近的竖向滚动祖先，用它驱动动画。换到具体场景：如果整个页面在滚动，nearest会命中html或body，效果和scroll(root)一样；如果某一段内容在overflow-y: auto的容器里，scroll(block nearest)会自动绑定到那个容器，不用在 JS 里判断滚动父级是谁。
早期规范还有一套“显式命名时间线”的写法：
.scroll-src { scroll-timeline-name: --hero-timeline; scroll-timeline-axis: block; } .hero-bg { animation-timeline: --hero-timeline; }这套写法在很多旧文章里出现，现在也有兼容价值。但新项目我更推荐直接用scroll()函数，一行声明就省掉了“给容器命名、再拿名称去关联”的中间步骤。
2.3 view() 与 view-timeline：看元素怎么穿过视口
如果说scroll()是“跟着滚动容器走”，view()就是“跟着元素本身走”。animation-timeline: view()会用元素进入视口的过程来驱动动画：从元素刚开始露出边缘，到完全离开视口，整个进度就是一条时间线。
对应的显式写法是view-timeline-name。真正上手时，我会这么做：
.reveal-card { view-timeline-name: --card-in; view-timeline-axis: block; animation-timeline: --card-in; animation: cardSlideUp 1s linear both; animation-range: entry 0% cover 40%; } @keyframes cardSlideUp { from { opacity: 0; transform: translateY(40px); } to { opacity: 1; transform: translateY(0); } }view-timeline-name和animation-timeline必须放在同一个元素上，才能让“自己进入视口的过程”驱动“自己的动画”。这也是我最喜欢的一点：以前做卡片进场动画，得用 IntersectionObserver 观察每个卡片，然后手动加类名；现在浏览器帮你完成了“观察”和“计时”这两件事。
2.4 animation-range：决定动画在时间线里的作用区间
动画绑定到滚动时间线之后，默认会从时间线 0% 播到 100%。但实战里你往往想限定区间：比如卡片刚露出 20% 就开始入场，到露出 60% 就结束；背景视差只在页面最开始的 80vh 内发生，后面保持不动。这时用animation-range。
语法一般写成两个关键词加百分比，例如：
animation-range: entry 0% cover 40%;这里的entry、cover是命名区间。基础概念的约定是：
entry：元素开始进入视口的那一段exit：元素开始离开视口的那一段cover：元素从完全在视口外到完全在视口内的全程
所以entry 0% cover 40%的意思是：从“刚开始进入视口”的 0%，一直播到“元素在视口中覆盖率达到 40%”的位置。再配合animation-range调整，入场动画和滚动位置就能精确对齐。
看完这段，你应该明白一个关键点：Scroll-Driven Animations 不是一个专门“做视差”的语法糖，而是一套“滚动进度驱动动画”的通用的底层机制。下面两套实战，就是基于这个机制往上盖楼。
3. 动手实现第一个视差页面：scroll() 版完整方案
3.1 需求与结构设计
我们要做一个三层视差场景：远处星空移动最慢、中间城市剪影稍微快一点、前景文字内容正常滚动。传统做法是一股脑把三层都塞进同一个容器里，然后监听页面滚动去换算位移。我的建议是先把“滚动容器”和“视觉层”分干净：
scene作为父容器，高度撑到180vh，让页面有足够滚动空间。- 所有视差视觉层都放在一个
position: sticky; top: 0; height: 100vh的背景壳里。 sticky的妙处是：背景壳在父容器滚动区间内始终钉在视口上方，给内部子层提供了一个稳定的表演舞台。
结构大致长这样：
<section class="scene"> <div class="scene__bg"> <div class="layer layer--stars"></div> <div class="layer layer--city"></div> </div> <div class="scene__content"> <h1>Scroll 不再监听</h1> <p>整段内容，随页面滚动自然呈现。</p> </div> </section>3.2 完整 CSS 实操代码
.scene { position: relative; height: 180vh; } .scene__bg { position: sticky; top: 0; height: 100vh; overflow: hidden; z-index: 0; } .layer { position: absolute; left: 0; right: 0; top: -10vh; bottom: -10vh; background-position: center; background-size: cover; will-change: transform; } .layer--stars { background-image: url('./stars.jpg'); animation: parallaxStars 1s linear both; animation-timeline: scroll(root); } .layer--city { background-image: url('./city.png'); animation: parallaxCity 1s linear both; animation-timeline: scroll(root); } @keyframes parallaxStars { from { transform: translate3d(0, 8vh, 0); } to { transform: translate3d(0, -12vh, 0); } } @keyframes parallaxCity { from { transform: translate3d(0, 4vh, 0); } to { transform: translate3d(0, -4vh, 0); } }3.3 为什么用 translate3d，以及位移量怎么定
注意上面的关键帧没有用top、background-position，而是统一走transform: translate3d。原因有两点：
第一，transform是合成器友好的属性，改动它不需要触发布局和重绘。top则可能引起重排；background-position虽然不重排，但视觉预算差很多。做视差要时刻记住一个原则：优先 transform，最好只动 transform 和 opacity。
第二，我用top: -10vh; bottom: -10vh把背景层上下各扩出 10vh，是为了给位移留出“拉扯冗余”。如果背景层死死贴着视口高度，向上移动一点就会露出底边；把元素扩出一圈，再在关键帧里做不越过边界的微调，视觉上才不会露馅。
位移量完全靠 vh 设定即可。比如星空层从8vh移到-12vh，实际位移 20vh；城市层从4vh移到-4vh，位移 8vh。远处的层位移大一点、近处的层位移小一点，原本静态的二维图片就有了纵深。这个比例没有绝对标准，我习惯按“远快近慢”的原则微调，直到快速滚动时层间速度差看起来舒服。
3.4 顺手做一个滚动进度条
既然已经在用scroll()，不加一个滚动进度条就太浪费了。进度条本质是“根滚动进度 0%→100%，元素宽度 0→1”：
.progress { position: fixed; top: 0; left: 0; width: 100%; height: 3px; background: #6c5ce7; transform-origin: 0 50%; z-index: 9999; animation: progressScale 1s linear both; animation-timeline: scroll(root); } @keyframes progressScale { from { transform: scaleX(0); } to { transform: scaleX(1); } }这里最容易踩的坑是transform-origin。scaleX默认以元素中心点缩放，从中间往两边展开，看起来像进度条“从中间顶出来”。设置成0 50%之后，它才会从左边刻度下面向右延展。一个进度条只要三行关键帧，比手写scrollY / documentHeight逻辑干净得多。
3.5 和 background-attachment: fixed 比，到底强在哪
很多人一看到“滚动背景”，脑子里第一个想法是background-attachment: fixed。它确实有一种视差效果，但有两个硬伤：在 iOS Safari 等移动端经常失效或卡顿；它只能让整块背景相对视口固定，没法做“两层背景以不同速度移动”的效果。而scroll()驱动的视差层可以一页叠多层，每一层有独立的@keyframes，真正做到分层控制。我在项目里把老的background-attachment方案整体迁移成scroll()之后，移动端的掉帧投诉明显少了很多。
4. 高频玩法：view-timeline 让卡片逐个浮起来
4.1 卡片入场的自动化：每个元素都有自己的进度条
上一节做完背景视差，你可能觉得“这跟 Ahooks 版的 IntersectionObserver 做法很像”。但 scroll-driven 更爽的点在于 view timeline 的场景。比如一个博客列表页，每张卡片在自己进入视口时淡入、上浮，用户不用管“当前可见卡片是哪几张”。
<div class="card">内容 1</div> <div class="card">内容 2</div> <div class="card">内容 3</div>.card { view-timeline-name: --card-in; animation: cardIn 1s linear both; animation-timeline: --card-in; animation-range: entry 0% cover 30%; } @keyframes cardIn { from { opacity: 0; transform: translateY(30px); } to { opacity: 1; transform: translateY(0); } }每张卡片都有自己独立的 view timeline。浏览器会在卡片刚进入视口的一瞬间把动画进度设为 0%，在卡片滚过cover 30%时把进度走到 100%。这段话翻译成人话就是：每张卡片都是自己故事的主角，不需要你去注册监听器。
4.2 用 animation-range 控制“看到哪里才开始动”
有读者可能会问：如果设置animation-range: entry 0% cover 100%，那动画会被拉得很长，可能卡片才露出四分之一时，动画就已经播完了。想要细腻控制“亮相节奏”，就要盯住animation-range。
我的常用参数是entry 0% cover 35%。这个区间给观众的感受是：卡片一露头，“欸它在动了”，然后滚到画面三分之一左右，动画收尾。而animation-range: entry 0% entry 60%则会让动画在卡片完全进入视口之前就结束，适合做“快速弹入”的强烈节奏。
调整 range 时，最有效的办法不是盲猜百分比，而是打开浏览器的 Animations 面板拖动时间线标记。后面第 6 节我会详细讲调试姿势。
4.3 图片视差变体：图片在固定容器里慢慢移动
view timeline 不只做透明度。让一个固定高度的容器里，背景图或 img 沿容器可视区移动，同样有视差感。常见做法是图片比容器更高，然后从位移 0 慢慢移到布景底部：
.media-scroller { height: 70vh; overflow: hidden; position: relative; view-timeline-name: --media; view-timeline-axis: block; } .media-scroller img { position: absolute; top: 0; left: 0; width: 100%; height: 130%; object-fit: cover; animation: imgDrift 1s linear both; animation-timeline: --media; animation-range: entry 0% exit 100%; } @keyframes imgDrift { from { transform: translate3d(0, 0, 0); } to { transform: translate3d(0, -30%, 0); } }这里的height: 130%配合translate3d(0, -30%, 0)是关键：图片超出容器 30% 的高度，位移 30%，刚好走完一个循环，又不会露出容器底边。移动端上，这种“图在框中缓慢漂移”的效果比整页背景视差更省资源，因为裁剪范围被限制在容器边界内，合成器负担小得多。
5. 兼容性与降级策略：别让旧浏览器看到空白
5.1 当前浏览器支持状态与检测方式
以我目前的实测经验，Chromium 系浏览器是主力支持方，Chrome 115 之后对scroll()、view()、animation-range的支持已经可用。Firefox 和 Safari 的支持状态跟 Chrome 相比还有差距，具体以你手上的 Can I Use 为准。前端上生产环境前，必须把兼容性降级当成功能的一部分。
建议用@supports把新特性包起来：
@supports (animation-timeline: scroll()) { .hero__layer { animation: parallaxStars 1s linear both; animation-timeline: scroll(root); } }如果浏览器不支持，这些层就是普通的绝对定位静态背景，页面依然可读。视觉上少了一点“高级感”，但不会崩。
5.2 用 CSS.supports 做渐进增强，而不是回归 JS 监听
有的团队一看浏览器不支持，马上就掏出老一套 JS scroll 监听。我的建议是：把 CSS Scroll-Driven Animations 当作渐进增强，而不是必须回退的底线。换句话说，不支持就让它静态陈列，也没什么问题。如果产品经理实在接受不了“完全无视差”，再在CSS.supports('animation-timeline', 'scroll()')通过时不加载 JS；不通过时再退回到轻量 IntersectionObserver 方案。至少“能跑新特性的环境，绝不用 JS 抢跑”。
5.3 永远给 prefers-reduced-motion 留个开关
无障碍不是一句口号。视差动画对晕动症用户很不友好，运动敏感人群看到持续位移的背景会恶心。标准做法是监听系统级“减弱动态效果”：
@media (prefers-reduced-motion: reduce) { .hero__layer, .card, .media-scroller img { animation: none !important; } }注意这里的animation: none也要把animation-timeline一起盖掉，因为旧浏览器可能不认识这两个属性，但animation简写是认识的。加!important是确保它不会被后续样式覆盖。
5.4 在 React/Vue 组件里使用时的小心机
框架项目里，组件卸载和复用时最容易出现“动画名冲突”。比如两个组件都定义了@keyframes parallaxStars，样式隔离没做好时，后加载的样式可能覆盖前一个。我的经验是：全局只维护一套带前缀的 keyframes 命名，比如sd-parallax-stars，组件里不要自己临时造动画名。另外，animation-timeline: scroll(root)与position: sticky组合在个别浏览器上会产生新的层叠上下文，给需要浮在上面的内容显式加z-index，能避免奇怪的重叠顺序。
6. 事故现场：常见问题排查与调优经验速查
6.1 动画没生效，先查这四件事
我见过不少朋友兴冲冲写上animation-timeline: scroll()，结果动画原地不动。排错顺序一般是：
- 确认元素有
animation-name，并且 keyframes 不是空实现。- 确认
animation-timeline没有被animation简写在后面覆盖。CSS 里后写的属性优先，如果你写了animation: fade ...再写animation-timeline，顺序没问题；反过来就白写了。- 确认你指定的 scroller 确实在滚动。如果元素处于一个
overflow: hidden的 div 里，nearest可能找到的不是你要的滚动容器。- 确认
animation-range没有把所有关键帧都切走。比如范围写成entry 0% entry 0%，动画被压缩到零区间里，自然看不到动效。
6.2 为什么位移节奏不对、忽快忽慢
Scroll-Driven Animations 依然遵守animation-timing-function。如果你没有显式设置，默认ease会把滚动进度重新映射一遍，结果就是：滚动均匀，但视差层忽快忽慢，跟手性很差。解决方式很简单：
animation: parallaxStars 1s linear both;给所有跟滚动进度相关的动画都加上linear。除非你有意制造“变速浮动”，否则线性是视差最可信的默认选择。
6.3 百分比用 vh 还是 %，别搞混
位移关键帧里-20vh相对视口，-20%相对元素自身尺寸。两者都能用，但含义完全不同：-20%在关键帧里会基于元素自身高度计算，如果你的层高是120vh，那么-20%就是-24vh。我用 vh 更多，因为视觉上更直观——我想让背景移动“小半屏”，直接写-30vh。但要记得把层上下扩大 10vh 到 20vh，给这 30vh 留出余地。
6.4 性能调优：两层就够，别叠七八层视差
CSS 方案再高效，也不代表可以无脑堆层。合成器要维护多个带will-change: transform的层，移动端内存吃不消。我把一个活动页从 6 层视差砍到 3 层，体感滚动反而更顺。建议是：背景远层、背景近层、前景内容，最多再加一个前景漂浮物，四层封顶。每增加一层，先用性能面板跑一轮，确认没有出现层爆炸再进行下一步。
6.5 DevTools 调试技巧：Animations 面板怎么用
Chrome DevTools 的 Animations 面板现在能直接看到 scroll timeline 的区间标记。展开 Elements 面板后选中元素，在 Styles 里能看到animation-range对应的可视化色条；拖动色条的端点，可以实时调整动画作用区间。这比在代码里改百分比再刷新快得多。
我的习惯是：先随便写一个较宽的区间，比如entry 0% exit 100%，在面板里观察元素滚动的起止位置，再逐步压缩端点，直到运动节奏符合预期。所有视觉参数都可以在这个面板里微调完，最后再把最终值带回代码。
6.6 别忘了硬性护栏：数值校验和容量控制
最后说一个容易忽略的工程化细节。viewport容器和animation-range一旦大量使用，页面里可能有几十个 view timeline。打开 Performance 面板，检查“Animations”相关耗时是否异常；如果只是大量简单淡入，建议把效果统一收敛到view()匿名时间线，而不是每个元素都创建带名字的view-timeline-name，增加命名空间的维护负担。
我在实际开发中还有一个习惯：把所有新特性的 CSS 包进@supports，并在注释里写明“这是 Scroll-Driven Animations，不支持时保持静态”。三个月后再回头维护，自己也不用重新猜为什么这段动画只在 Chrome 生效。如果你也想从 JS scroll 监听里彻底脱身，不妨从今天这个标题开始：先拿一个页面里的背景层做实验，用scroll()替换掉最卡的那段监听，再一块块迁移，最终你会发现，浏览器原生给出的答案，往往比我们手动拼装的补丁方案更优雅也更省心。
