企业官网建设流程全解析

我一直觉得，前端动画这条路上，有两类人：一类是打开别人做的网页，觉得“卧槽这交互真顺滑”然后止步于此；另一类是按下F12翻源码，非要把那几行JS琢磨明白不可。如果你属于后者，又恰好对滚动动效感兴趣，那今天这篇东西你应该会看得过瘾。咱们要聊的就是GSAP生态里那个几乎绕不开的插件——ScrollTrigger。说句实在话，我早些年做滚动动画，用jQuery插件加监听scroll事件手动算距离，那真是又累又糙。后来换了ScrollTrigger，才知道什么叫“用对了工具，效率翻倍”。

1. 先搞清楚ScrollTrigger解决什么问题

1.1 从滚动动画的痛点说起

你回想一下自己写滚动动画的过程。最原始的做法：监听window的scroll事件，在回调里读scrollTop，然后根据距离去改元素的transform或者opacity。听起来不难，但等你真正做三五个带有视差、固定定位、进度条效果的页面，你就会发现麻烦接踵而至。

第一个麻烦是性能问题。scroll事件在滚动时会高频触发，你要是没有用requestAnimationFrame做节流，页面上贴几十个动画节点，在低端手机上一顿操作猛如虎，页面的帧率早就掉成PPT了。第二个麻烦是计算逻辑。一个元素从进入视口到完全离开视口，它的“生命周期”需要你自己算出start和end两个临界点，再去映射动画进度，这个过程涉及viewport高度、元素偏移量、滚动容器偏移量等一堆变量，写完自己都容易绕晕。第三个麻烦是状态管理。动画触发一次之后要不要停止？用户往回滚要不要重置？多个动画之间有依赖关系怎么协调？这些全靠手写的话，代码会迅速膨胀到不可维护。

ScrollTrigger就是为了把这些脏活累活一锅端掉而存在的。它帮你处理滚动监听、视口计算、位置映射、状态切换这些事情，你只需要关心一句话：元素在滚动的哪个阶段做什么样的变化。

1.2 ScrollTrigger在GSAP生态中的定位

先补充一点背景知识。GSAP（GreenSock Animation Platform）是一个老牌的、与框架无关的JavaScript动画库，核心引擎叫TweenMax和TimelineMax（4.0之后统一为gsap核心包）。它做动画的核心优势在于把动画过程抽象成“补间”（Tween），即从一个状态平滑过渡到另一个状态，配合缓动函数控制速率变化，你不需要写任何计时器。

ScrollTrigger是GSAP官方维护的插件之一，专门负责把GSAP的补间能力跟“滚动位置”做绑定。换句话说，GSAP解决“怎么动”的问题，ScrollTrigger解决“什么时候动”的问题。

这套组合拳打出来，你会得到几个很实在的好处。第一，代码量缩减幅度肉眼可见。原来几十行滚动计算逻辑，现在一句ScrollTrigger.create就能替代大半。第二，原生滚动支持顺滑体验。它默认采用的是浏览器原生滚动，没有引入虚拟滚动容器，因此滚动条手感跟页面原始体验保持一致。这在追求真实滚动体验的页面里非常重要。第三，配套能力强。刷新后位置自动校准、响应式配置、动画反向播放、时间线控制等等，全是现成API，用起来非常连贯。

我自己的感觉是：如果项目需求是常规的滚动动效，比如滚动淡入、视差移动、固定元素切换等，用ScrollTrigger几乎是对解法的最优选择。它不是唯一能用的方案，但它好用、简单、稳定，生态成熟度高。

2. 核心配置项逐个拆解，这才是高手与新手的分水岭

2.1 trigger、start、end：三个最基础也最容易搞混的配置

ScrollTrigger的配置项很多，但你把它拆开来看，底层逻辑其实就三件事：以哪个元素为参照物（trigger）、动画从哪个滚动位置开始（start）、到哪个滚动位置结束（end）。

trigger是一个选择器字符串或者DOM元素，用来指定哪个元素作为这个动画的触发基准。比如你要做一个列表项逐个淡入的效果，trigger就指向列表容器本身；要做某个图片的视差效果，trigger就是那张图片。

start和end是字符串，默认格式是"top top"之类的，形式是“元素位置 + 视口位置”。这里的“元素位置”和“视口位置”你有两种选择：一种是top、center、bottom这样的关键词，表示元素或视口的顶边、中心、底边；另一种是数字或百分比，比如"20px"或"30%"。

超绕的一点是：默认情况下，start"top top"表示元素顶部到达视口顶部时，动画开始。而视口的顶部再向下偏移一定距离，则定义为"top top+=100"这种写法，表示元素顶边在视口顶边之下100px位置时触发。

end是动画结束的滚动位置，它决定了动画推进的区间跨度。常见写法比如"bottom top"，表示元素底部到达视口顶部时结束。一个非常典型的十字交叉写法是：start为"top bottom"（元素顶边碰到视口底边，即刚露头），end为"bottom top"（元素底部离开视口顶边，即完全离开）。这样写下来，动画正好贯穿元素在视口中完整出现的整个区间。

新手最容易犯的错是把start和end的记忆搞反。我自己总结了顺口溜：start是“谁碰到谁”，end是“谁离开谁”。举例说明：start: "top bottom"，前面的“top”指元素的顶边，后面的“bottom”指视口的底边，整句意思就是“元素的顶边碰到了视口的底边”。同理，end: "bottom top"，意思是“元素的底边碰到了视口的顶边”。这样拆开来记，就不乱了。

2.2 scrub与pin：让动画和滚动“咬合”在一起

如果你想让动画进度跟滚动位置形成一对一的关系，而不是“到达某个位置才播放”，那就必须认识scrub这个配置。它有两种传参方式：scrub: true表示动画进度完全跟着滚动走；scrub: 1则是带有一点“惯性跟随”效果，数字代表时间，数值越大，动画对滚动的跟随就越有延迟感、越柔和。

带延迟的scrub效果很适合做视差。视差的核心就是“不同层移动速度不同”，如果你让每个层的动画都跟着滚动做映射，再微调不同的scrub尾巴，层与层之间的错动感就出来了。同样一个背景图和前景文字，前景的scrub值设成1.5，背景的设成2.5，滚动起来感觉就会完全不同。

pin是“固定”的意思，它会让trigger元素在动画区间内固定在原地，等动画结束后再释放。这个效果常用来做“滚动切换全屏区块”或者“某个元素先固定、后续内容覆盖过去”的页面结构。

pin的实现原理其实非常有意思。ScrollTrigger会把被固定元素包进一个高度等于视口高度的父容器，同时通过transform或者position把它钉在视口上。所以你在使用pin时要注意：它会产生额外的嵌套DOM结构，检查页面元素时看到多出来的包裹层不要慌，那是ScrollTrigger干的。

用pin时还有一个容易踩的小坑：如果你销毁了ScrollTrigger但没有销毁pin的包裹层，会出现页面排版错乱。正确做法是通过ScrollTrigger提供的清理方法，让插件在销毁实例时一并把pin结构还原。

2.3 toggleActions：精确控制动画的四种动作

toggleActions是定好“在什么位置做什么事”的开关集合。它接收四个字符串，依次对应：动画区域开始（onEnter）、完全激活（onEnterBack）、完全离开（onLeave）、反向进入（onLeaveBack）时的行为。

每个位置的行为可以是play、pause、resume、reset、restart、complete、none中的一种。默认值是play none none none，意思是进入时播放，之后就不管了。这个配置的典型应用场景是：某个动画只希望用户滚动经过时播放一次，播放完就保持结束状态，不反向播放。

我来举个实际做过的例子，帮助你理解toggleActions的妙用。之前做一个官网的“技能雷达图”板块，需求是雷达图的刻度线像雷达扫描一样依次扫出来，用户不管往下滚还是往回滚，这个动画都只在首次进入时播放一遍，之后固定结束状态。开始我的配置是默认值，往回滚动时动画就会反向播放，刻度线缩回去，视觉上非常奇怪。后来把toggleActions设成play none none none，问题立刻解决。

注意一点：toggleActions只对非scrub模式生效。一旦你开了scrub，动画进程本身就是由滚动位置驱动的，此时toggleActions基本没有意义。两者是“播放模式”和“绑定模式”的区别，不能混用。

3. 从零实现一个完整案例，把配置项串起来

3.1 页面结构准备

空谈理论容易飘，直接上一个能跑通的项目例子。假设我们要做一个偏品牌展示的横版页面，包含三个部分：

• 首屏是一段大标题，滚动时字体会做视差上移并逐渐淡出；
• 中间是一个横向滚动的“服务介绍”区域，用户往下滚时，内容横向平移；
• 底部是几个卡片，逐个淡入上移。

技术栈直接用原生HTML/CSS/JavaScript加GSAP的CDN引入，不掺框架，方便你把原理看清。

首先在HTML头部引入GSAP和ScrollTrigger：

<script src="https://cdn.jsdelivr.net/npm/gsap@3.12.5/dist/gsap.min.js"></script> <script src="https://cdn.jsdelivr.net/npm/gsap@3.12.5/dist/ScrollTrigger.min.js"></script>

这里有个细节：CDN版本锁定。建议直接指定具体的版本号，不要用latest去拉。原因很简单：GSAP更新后API可能会有新特性，但不一定完全向后兼容，你写着写着代码突然行为变了，定位半天才发现是CDN偷偷升版，非常浪费时间。

然后在JS里注册插件：

gsap.registerPlugin(ScrollTrigger);

这一步不能省。虽然GSAP官方支持不注册直接使用部分功能，但ScrollTrigger的很多特性依赖注册流程来初始化。不注册的话，部分API会静默失效，排查起来非常痛苦。

3.2 基础滚动动画实现

先做首屏标题的视差淡出效果：

gsap.to(".hero-title", { yPercent: -80, opacity: 0, ease: "none", scrollTrigger: { trigger: ".hero", start: "top top", end: "bottom top", scrub: true } });

我来解释一下这里的关键动作。yPercent: -80表示元素沿着Y轴负方向移动自身尺寸的80%，视差效果的本质就是让元素移动速度跟滚动速度不一致，这里实现的是慢速上移加淡出。ease: "none"在scrub模式下非常重要，因为它保证了动画跟滚动的线性一致，如果你这里填了默认的power1.out，你会发现动画跟滚动手感不匹配，忽快忽慢。

start: "top top"是让动画从标题区域顶部到达视口顶部时启动。这样写，页面刚加载时标题静止不动，往下滚立刻开始上偏移和淡出，体验上非常自然。

3.3 横向滚动区域怎么做

横向滚动区域是ScrollTrigger一个比较炫酷的用法，实际上它仍然是一个“纵向滚动驱动横向位移”的映射问题。

const container = document.querySelector(".horizon-wrapper"); const sections = gsap.utils.toArray(".horizon-section"); gsap.to(container, { x: () => -(container.scrollWidth - window.innerWidth), ease: "none", scrollTrigger: { trigger: ".horizon", start: "top top", end: () => "+=" + (container.scrollWidth - window.innerWidth), pin: true, scrub: 1, anticipatePin: 1 } });

核心思路是：把横向容器的x位移跟滚动长度做映射。x的终点是-(容器总宽度 - 视口宽度)，这刚好是横向滚动到最右侧所需的移动量。end同理，用一个函数来动态计算总滚动距离，页面宽度变化时刷新也能保持正确。

anticipatePin: 1是个容易被忽视但很有用的配置。pin开启后，元素被固定时浏览器会临时调整滚动条位置，这可能导致动画起点有一点点“跳”。anticipatePin这个参数会让ScrollTrigger在pin生效之前先对其未知运动做好处理，提前补偿，这样视觉上更顺滑。

还有一点必须提醒：横向滚动区域的父容器一定要设置overflow: hidden，否则横向位移会撑破页面出横向滚动条。这个坑我踩过，页面右侧突然出现一条长滚动条，调了半天CSS才发现是这个原因。

3.4 卡片逐个淡入的写法

底部卡片的逐个淡入，推荐用批量创建动画的方式：

const cards = gsap.utils.toArray(".card"); cards.forEach((card, index) => { gsap.from(card, { y: 60, opacity: 0, duration: 0.8, delay: 0.1 * index, scrollTrigger: { trigger: card, start: "top 85%", toggleActions: "play none none reverse" } }); });

这里用gsap.from定义初始状态，元素进入视口时从位移60px、透明度0的状态变化到默认状态。start: "top 85%"的意思是元素顶部到达视口高度85%的位置时触发，也就是元素还没完全进入视口之前就开始动了，这样视觉上会有“提前进入”的层次感。

delay: 0.1 * index实现了卡片依次错开进入的效果。这个延迟在非scrub模式下是有效的，但如果开了scrub，delay会被滚动位置映射覆盖，两者不要同时使用。

4. 项目上线前后必看的踩坑记录与性能优化

4.1 动态内容引发的“定位漂移”问题

这是我一再强调的问题：如果页面里还有图片（尤其是没设固定高度的横幅）、异步加载的内容、字体加载替换等，ScrollTrigger计算出来的触发位置可能一开始就是错的，或者刷新后变了。

举个例子，页面里有张大图，加载完成后占位高度从0变到实际高度，这会导致它下方所有元素的offsetTop全部变大。ScrollTrigger在创建实例时记录的start/end位置是基于当时页面状态的，图片加载完、字体替换后，这些位置就过期了。

解决办法有几个。最简单的：给图片、视频容器设置固定的宽高比，用CSS的aspect-ratio来占位，避免加载后布局跳动。如果避免不了动态内容，可以在内容加载完成后手动调用：

ScrollTrigger.refresh();

这个API会重新计算所有实例的起止位置，是动态页面必备。如果你用了React/Vue这类框架，可以在数据更新后的nextTick里调用它。另一种更精细的做法是给ScrollTrigger实例配置onRefreshInit或onRefresh回调，做属于自己的重置逻辑，但大多数项目用refresh就够了。

4.2 移动端与iOS的坑，说多了都是泪

移动端的坑跟浏览器处理滚动的方式直接相关。现代浏览器把滚动拆成了“主线程”和“合成器线程”两个层次，如果ScrollTrigger实现的动画是直接操作transform/opacity，那么合成器可以独立处理，性能问题不大。但一旦操作了会引起布局的属性，比如width、height、top、left，就会退回到主线程计算，低端机直接卡成狗。

在iOS Safari上有一个需要额外注意的点：滚动结束后的惯性滚动（momentum scrolling）不会触发连续的scroll事件，而是直接“甩”到终点位置。如果动画是scrub模式，它可能会直接跳到最终状态，或者出现中间帧缺失的闪烁感。在我实际项目中，遇到这个问题的解决思路是：主要动效在移动端做减法，保留淡入淡出和轻微位移，复杂视差留在桌面端体验。

还有一个小技巧是给body加overscroll-behavior: none，避免页面滚到边缘时触发浏览器回弹效果，回弹会让ScrollTrigger的pin固定发生跳动，尤其在双指缩放和下拉刷新场景下特别明显。

4.3 性能优化：聪明地使用will-change和懒加载

GSAP动画本身操作的是transform和opacity，合成器能直接处理，所以性能瓶颈通常不在动画，而在浏览器对元素的图层管理。默认情况下，浏览器可能不会为每个动画元素单独创建合成层，如果你做了大量transform动画，反而会导致频繁的重绘和重排。

解决方案是给那些大范围移动的元素加：

.will-move { will-change: transform; }

但这里必须强调：will-change不是越多越好。每个will-change: transform都意味着浏览器要额外分配一块内存做硬件加速层，几十个元素都加，内存占用就上去了，低端设备内存吃紧反而更卡。我的经验是只给始终运动的元素（比如视差层、pin容器内部的大型元素）加，静态元素不动，完全不需要这个属性。

另一个优化方向是懒创建ScrollTrigger实例。项目页面往往有很多区块，如果一进来就全部实例化，即便没有滚动也会去计算几何布局，有些浪费。可以通过ScrollTrigger.config({ ignoreMobileResize: true })忽略移动端地址栏伸缩导致的resize重算，或者自己写一个IntersectionObserver来代理初始化，但后者属于锦上添花，不是必须。一般项目里直接全量实例化，配合定期refresh，完全够用。

4.4 在Vue和React框架里的真实体验

现在前端项目几乎都是用框架写。在React里用ScrollTrigger有一个经典大坑：StrictMode下开发环境会执行两次组件挂载，ScrollTrigger实例可能被重复创建。

这是因为React 18的StrictMode会模拟组件的卸载和重挂载，如果useEffect的清理函数没有正确销毁ScrollTrigger实例，第二次挂载又新建了一个，同一个动画区域就会产生两个实例，来回滚动时触发位置互相干扰，动画表现错乱。

解决办法很简单：在useEffect清理函数里调用：

useEffect(() => { const tween = gsap.to(...); return () => { tween.scrollTrigger && tween.scrollTrigger.kill(); tween.kill(); }; }, []);

如果一次性创建了多个实例，也可以统一清理：

ScrollTrigger.getAll().forEach(st => st.kill());

在Vue里情况类似，在onUnmounted钩子中做同样的操作。Vue 3里推荐使用gsap.context，它能把动画和组件实例做绑定，清理时一次性处理，非常优雅。

框架集成还有一个小坑：组件卸载后，ScrollTrigger的回调可能还会被触发。如果回调里访问了已卸载的DOM元素，会报null指针错误。所以我在清理时都会做一个空值判断，防止异步滚动事件里踩雷。

5. 从使用到进阶：能提升你效率的几个冷门但好用的技巧

5.1 用“函数 + 动态值”让配置自适应

ScrollTrigger的start、end、x位移等值，不仅仅支持固定字符串，还支持函数。你每次写死数值都可以想一想，页面宽度变了这个值还合适吗？

比如我们要做的横向滚动位移，直接写死1000px当然能跑，但在不同屏幕下就会出现要么位移过远、要么不够到位的情况。用动态函数写法，每次执行都重新读取当前尺寸，响应式无忧。

我习惯的做法是：把项目中所有用到宽度、高度计算的地方统一封装成函数，在refresh事件里来自动重算。ScrollTrigger的onRefresh回调就是专门干这个的。如果用了ResizeObserver做容器尺寸监听，也可以触发refresh来刷新位置。

5.2 利用ScrollTrigger的onToggle监听进入/离开

很多需求需要你在元素进入视口时去切换类名，比如当前导航高亮、某个区块激活计数器等。ScrollTrigger的onToggle回调比你自己写监听器来准确判断元素是否在视口内要省事多了。

ScrollTrigger.create({ trigger: ".section-2", start: "top center", end: "bottom center", onToggle: (self) => { if (self.isActive) { // 元素进入中心区域 } else { // 元素离开中心区域 } } });

这里self.isActive是判断当前是否处于动画区间中间的开关。做单页导航高亮、横向指示器跟随，这个模式简直不要太合适。

5.3 配合gsap.context做作用域隔离

最后再分享一个小技巧：在原生JS或框架组件里，我都会用gsap.context()把所有动画包裹起来。它的作用是把当前函数里创建的动画和ScrollTrigger实例记录到一个上下文对象中，后续调用ctx.revert()就能把这段创建的东西全部还原，包括DOM的inline样式和pin结构。

const ctx = gsap.context(() => { gsap.to(".hero-title", { ... }); ScrollTrigger.create({ ... }); }, containerRef); // 清理时 ctx.revert();

这个API的好处是改代码时不用逐个查找变量去清理，一个revert搞定。写复杂页面时，强烈建议养成用context的习惯，尤其是组件化开发中，它会帮你省下大量排查“动画残留”的时间。

ScrollTrigger在我的项目里已经成了“默认选项”。它带着一套完整的计算和状态管理方案，把滚动动效的门槛拉到了很低，但真正做得流畅、做得有质感，还需要你对它底层的滚动映射和pin机制有足够理解。说到底，工具只是棍子，功夫在手上。遇到复杂布局，你自己心里要清楚trigger和视口的位置关系；遇到卡顿，你要能判断是图层性能还是计算逻辑的问题；遇到框架集成，你得知道实例什么时候销毁、位置何时刷新。把这几点吃透，ScrollTrigger对你来说就不再是一个需要查文档的插件，而是一个随手就能用的家常工具。