企业官网建设流程全解析

做前端这些年，大大小小项目里，“传送带动画”这种需求我至少遇见过七八次。电商首页的促销商品滚动、物流大屏上的货物流转、品牌站主视觉里的物品穿梭、甚至一个简单的公告跑马灯，表现形式各不相同，但底层逻辑几乎都一样——让一组元素沿着固定方向平滑地、无限地循环移动。

这个动画听起来简单，真正落地时却有不少门道：怎么做到首尾无缝拼接？怎么让物品像真实流水线那样一个个“上料”再“下料”？动画跑起来卡顿掉帧该怎么办？这篇文章我就把这些年在实际项目里踩过的坑、沉淀下来的方案一次性整理出来，从纯CSS的最简写法，到JS控制的动态传送带，再到沿曲线路径运行的进阶版本，全部给可直接复用的代码和参数计算过程。

1. 传送带动画在真实项目里解决什么问题

1.1 先看清需求的“变体”再动手

传送带动画本质上是一种“循环位移动画”，但不同业务场景对它的要求差别很大。我习惯先给需求分类，因为不同的分类直接决定使用哪种技术方案。

第一种是整体移动型。最典型的就是电商首页的品牌Logo墙或者优惠券跑马灯：一排内容全部以相同速度向同一方向移动，循环往复。这种方案通常不需要JS参与，纯CSS就能做到极致流畅，核心是“复制内容 + transform位移”。

第二种是个体出入型。比如物流监控大屏上，包裹从画面右侧进入传送带，一路滑到左侧出货口然后消失；再比如生产车间的物料流转可视化。每个物品有独立的生命周期：出现、移动、消失，物品之间保持固定间隔。这种方案必须用JS来管理节点的创建和销毁，或者用动画队列来控制每个元素的运动。

第三种是路径跟随型。传送带不是直的，可能是一个环形、一个S形，或者像机场行李转盘那样的椭圆轨迹。纯CSS的直线位移就搞不定了，需要用到SVG的animateMotion、CSS的offset-path，或者引入专业的动画库。

除了这三种，你还需要提前问自己几个问题：内容是否固定不变？循环方向是左到右还是右到左？速度恒定还是允许用户拖拽/调速？需要鼠标悬停时暂停吗？这些问题的答案，决定了你有没有选对实现路径。我见过不少同事在“其实只需要一个跑马灯”的需求上用上了整套动画框架，维护成本很高，没必要。

1.2 用“机器模型”拆解传送带动画

我习惯把传送带动画拆成三个机械部件来思考：驱动（什么力量让物体移动）、轨道（物体沿什么路径走）、接口（物体如何进出轨道）。

驱动对应的是动画的计时和速度曲线。线性动画是传送带的默认选项，因为真实传送带不会加速减速。如果希望入场和出场时有一点缓冲，可以给个体动画单独加ease-in或ease-out，但整条带子上的匀速感一定要保留，否则视觉上会很“假”。

轨道对应的是位移方式。直线位移用transform就够了，曲线路径则需要换一套坐标系统。轨道还有个重要属性是“无限性”，也就是无缝循环——这是传送带动画最容易出bug的地方，后面我会专门展开讲。

接口对应的是内容的进出机制。整体移动型的接口就是“HTML里复制一份内容”，个体出入型的接口是“JS按时间间隔创建节点”，路径跟随型的接口则更关注每个物品沿着路径走完一圈之后怎么回到起点。

把这三个部件想清楚，你写代码的时候会非常有条理，而不是网上随便抄一段跑马灯代码凑数。

2. 基础款：纯CSS无缝传送带动画

2.1 结构设计：为什么必须复制一份内容

先看一个最简可用的HTML结构：

<div class="conveyor"> <div class="conveyor__track"> <ul class="conveyor__list"> <li>商品 A</li> <li>商品 B</li> <li>商品 C</li> <li>商品 D</li> <li>商品 E</li> </ul> <ul class="conveyor__list" aria-hidden="true"> <li>商品 A</li> <li>商品 B</li> <li>商品 C</li> <li>商品 D</li> <li>商品 E</li> </ul> </div> </div>

核心思路是：轨道里放两份完全相同的内容，然后让整个轨道位移“一份内容”的宽度，再瞬间跳回起点。因为第二份内容和第一份一模一样，跳回起点的瞬间人眼根本察觉不到，这就实现了无缝循环。

为什么不能只放一份内容然后从0位移到100%再跳回0？因为往回跳的那一瞬间，画面会明显“倒带”，像视频卡顿一样，观感非常糟糕。复制一份内容相当于把“回到起点”的动作藏在了画面之外。

第二份列表我加了aria-hidden="true"，这是给读屏软件看的标记，告诉辅助技术这一份是装饰性副本，不要让视障用户朗读两遍同样的商品列表。无障碍细节很多人忽略，但遇到了相关需求时，这一行就是加分项。

2.2 动画参数计算：时长、位移、速度

接下来是CSS：

.conveyor { overflow: hidden; border: 1px solid #e5e5e5; border-radius: 8px; } .conveyor__track { display: flex; width: max-content; animation: conveyor-move 10s linear infinite; } .conveyor__list { display: flex; flex-shrink: 0; gap: 20px; padding-right: 20px; } @keyframes conveyor-move { from { transform: translateX(0); } to { transform: translateX(-50%); } }

这里有几个细节我特意处理过。轨道用了width: max-content，让宽度由内容撑开，而不是被子元素的百分比约束。列表加flex-shrink: 0，防止在容器空间不足时flex压缩列表宽度导致动画“漏底”。gap保证卡片之间等距，而每份列表末尾额外补一个和gap等宽的padding-right，是为了让两份内容拼接处的间距和其他地方完全一致，否则滚动到拼接点时你会看到间距突然变小，露出一道“焊接口”。

关键来了，动画时长怎么确定。很多人喜欢随便填一个10s，然后发现速度不对再瞎调。其实传送带的速度是可以准确计算的。

translateX(-50%)里的百分比是针对conveyor__track自身的宽度，而轨道内有两份列表，所以位移50%刚好等于一份列表的总宽度。假设一份列表总宽为C，你期望的移动速度是v像素每秒，那动画时长就是：

时长T（秒） = C / v

举例来说，一份列表里放5张卡片，每张宽240px，间距20px，末尾还有20px padding，那么：

C = 5 × 240 + 4 × 20 + 20 = 1300px

如果你想让内容以大约200px/s的速度滚动，那么：

T = 1300 / 200 = 6.5s

把6.5秒填进animation-duration就行。以后要按业务要求加速或减速，直接用这个公式反推，不需要靠肉眼一点点试。

我再补充一个很多新手会遇到的情况：内容总宽度不够，复制两份后滚动方向会出现空白区域。比如一份列表只有300px宽，视口却有800px，复制两份后总宽600px，位移一份的宽度之后，第二份走完，整个轨道已经在视口里露出大段空白。

解决办法其实很简单：复制多份，直到所有副本的总宽度大于“视口宽度 + 一份内容宽度”。如果复制了N份，动画的位移百分比就不是-50%了，而应该是-100/N%。比如复制3份，总宽度就是3C，位移一份C占轨道的1/3，所以位移目标应该是translateX(-33.333%)。

2.3 悬停暂停与播放状态控制

用户鼠标悬停在传送带上时暂停，是最常见的交互需求。CSS里直接用animation-play-state：

.conveyor:hover .conveyor__track { animation-play-state: paused; }

就这么简单。但要小心一个坑：如果卡片本身有hover效果，比如放大、加阴影，你再把暂停事件挂在.conveyor上，鼠标在卡片上晃动时有可能触发整个轨道的暂停和恢复。视觉上表现为传送带一卡一卡的，体验很差。我的做法是给每个卡片单独做pointer-events控制，或把hover暂停放在卡片上：

.conveyor__card:hover ~ .conveyor__track { animation-play-state: paused; }

但这种兄弟选择器结构上不太好组织，实践里更稳妥的是在卡片hover时暂停轨道、离开卡片时恢复——用JS监听mouseenter和mouseleave来切换轨道class，代码虽然多几行，但行为完全可控。

另外注意：一旦轨道暂停的时间足够长，用户会看到一张卡片卡在视口里。如果你希望在暂停时卡片还能被点击跳转，那在卡片元素上做链接，别让轨道整体覆盖事件。传送带归根到底是装饰层，内容的可点击性优先级最高。

3. 升级款：带物品进出的动态传送带

3.1 用JS构造队列，让物品逐个“上料”

纯CSS能解决整体滚动，但真实业务里更常见的是“物品一个接一个进入传送带，走完一段路后离开”。这种需求适合用JS来管理物品生命周期。

先看结构：

<div class="line"> <div class="line__belt" id="belt"></div> </div>

JS核心逻辑如下：

const belt = document.getElementById('belt'); function createItem(name) { const el = document.createElement('div'); el.className = 'line__item'; el.textContent = name; return el; } let index = 0; setInterval(() => { const el = createItem(`货物 ${index + 1}`); belt.appendChild(el); // 从右侧视口外滑入，滑到左侧视口外后移除 const distance = belt.clientWidth + el.offsetWidth; el.animate( [ { transform: `translateX(${belt.clientWidth}px)` }, { transform: `translateX(-${el.offsetWidth}px)` }, ], { duration: 6000, easing: 'linear', } ).finished.then(() => { el.remove(); }); index++; }, 1500);

这里使用了Web Animations API，现代浏览器原生支持，不需要额外引入动画库。每个物品创建出来时定位在容器右侧视口之外（translateX(belt.clientWidth)），然后线性移动到左侧视口之外（translateX(-el.offsetWidth)），动画结束后通过finishedPromise移除节点。

有几个参数需要你自己算一下。setInterval的间隔决定了“上料频率”，每一项的动画时长决定了“在传送带上停留的时间”。它们共同决定传送带上同时存在的物品数量：

同时存在的物品数 ≈ 动画时长 / 上料间隔

上面代码里动画时长6000ms、上料间隔1500ms，所以同时存在约4个物品。如果你发现物品在传送带上重叠了，就把间隔调大；如果传送带显得太空，就缩短间隔或加长动画时长。这种“频率与时长”的换算关系，是我每次调这类动画的第一思考路径。

性能方面有个细节：如果物品数量特别多，比如商品列表有几百个，不要一次性全部appendChild，而是像上面这样按需创建、动画结束后立刻remove。这样DOM节点数量始终受控，页面不会越跑越卡。

3.2 沿曲线走：SVG路径与CSS offset-path

直线传送带做多了，总会碰到要求“S形”“环形”“折返形”轨道的大屏项目。这时候transform明显不够用，因为你没法用translateX/Y组合精确描出一条曲线。

最保守、兼容性最好的方案是SVG配合SMIL动画。你只要画好路径，把元素挂进去：

<svg class="route" viewBox="0 0 900 300"> <path id="beltPath" d="M50,60 H250 C350,60 350,150 450,150 H820" fill="none" stroke="#cbd5e1" stroke-width="2" /> <circle r="14" fill="#4f46e5"> <animateMotion dur="5s" repeatCount="indefinite"> <mpath href="#beltPath" /> </animateMotion> </circle> </svg>

SMIL的好处是写起来非常直观，路径用d属性画成什么样，元素就跑什么样。缺点是JS交互能力弱，想暂停、跳转、监听单个物体到达终点，都比较别扭，而且少数老版本WebView对SMIL的支持有坑。

现代浏览器更推荐用CSS的offset-path。同样一条路径，CSS版本是这样的：

.route__box { offset-path: path('M50,60 H250 C350,60 350,150 450,150 L820,150'); offset-rotate: 0deg; animation: run 5s linear infinite; } @keyframes run { from { offset-distance: 0%; } to { offset-distance: 100%; } }

offset-distance从0%走到100%，元素就会沿着offset-path定义的路径走完一整条。offset-rotate: 0deg可以让元素始终保持水平方向而不是跟着路径旋转，做包裹类图标时一般都用这个设置。

这个方案的优点是纯CSS、无依赖、可暂停（animation-play-state依然有效），缺点是对浏览器版本有要求，好在近几年的主力浏览器都支持了。如果你需要在很老的WebView里运行，再退化到SMIL方案也不迟。

3.3 什么时候值得上动画库

我见过很多团队，做一个公告跑马灯也要引入GSAP。我的态度是：先问自己三个问题，再决定要不要上库。

第一，是否只有一个无限循环动画？如果是，纯CSS足够。第二，是否有多个物品需要交错控制？如果是，Web Animations API也能满足，没必要上库。第三，是否有复杂的贝塞尔曲线、时间轴编排、scrub滚轮联动？这种高端玩法才轮到GSAP出场。

GSAP真正强的地方是Timeline，可以把多个子动画精确排布在一条时间轴上，比如“物品先沿路径走2秒、然后缩放到0、同时下一个物品开始入场”。如果你在做一个复杂的物流3D可视化大屏，这种编排能力能省大量时间。但代价是库的体积和额外的学习成本。

我用过一个比较务实的组合：主体滚动用纯CSS，物品出入用WAAPI，真遇到复杂时间轴再用GSAP的Timeline单独做某一小块。这样大部分页面不需要加载动画库，需要的时候也只在小范围内引入，整体性能和维护成本都可控。

4. 性能和衔接优化：不掉帧、不闪断的进阶技巧

4.1 为什么必须用transform而不是改left

从浏览器渲染机制看，改变一个元素的left、top、width、height，会触发浏览器的layout（重排）过程，浏览器需要重新计算整个文档的几何位置关系。紧随其后还有paint（重绘），最后才是**composite（合成）**上屏。这一整条链路跑下来，每帧的消耗都非常大。

而transform和opacity是合成器属性，改动它们只触发composite阶段，不触发layout和paint。所以传送带动画里，你看到的所有位移都应该用transform: translateX()或translate3d()驱动，不要用left或margin-left。

一句话总结：让动画元素脱离正常文档流，用绝对定位 + transform来控制坐标。这样浏览器可以把动画元素单独提取到一个合成层，每一帧只需要做图层移动，性能天差地别。

另外，老浏览器对translateX的合成优化不积极，必要时可以用translate3d(0, 0, 0)强制开启GPU合成层。但新浏览器里没必要加，加了反而可能多创建不必要的层。我的习惯是只在出现掉帧问题的时候再加translateZ(0)，而不是一开始就全部铺上。

4.2 无缝衔接的三个隐蔽边界

第一个隐蔽边界是两份列表的间距一致性。前面提到用gap和padding-right对齐拼接处，但如果你使用margin-right给卡片加间距，要注意最后一张卡片的margin不能少。更稳妥的做法是用每一项统一margin，然后列表末尾不做额外处理，而是复制后两份内容保持不变——但如果这样，拼接处相当于两份内容之间没有margin。所以我始终建议用gap + padding的方案，算起来一目了然。

第二个隐蔽边界是宽度计算时机。如果列表里有图片，而图片还没加载完成时你就量了宽度，计算出来的动画时长会偏小，图片加载完列表变宽，速度就变了。遇到图片场景，可以等window.load事件触发后再设置动画时长，或者干脆用CSS变量让时长跟随内容宽度自动变化，JS量一次写入：

const track = document.querySelector('.conveyor__track'); const list = document.querySelector('.conveyor__list'); const width = list.offsetWidth; track.style.setProperty('--belt-duration', `${width / 200}s`);

CSS里这样写：

.conveyor__track { animation-duration: var(--belt-duration, 10s); }

第三个隐蔽边界是字体加载引起的宽度变化。网页字体的font-display: swap特性会导致初始渲染用降级字体，网络字体加载完后又用正文字体，文本宽度随字体变化。对传送带来说，这会造成动画开始后轨道宽度突然变宽，无缝拼接被破坏。处理方式有两种：简单粗暴地在animate容器里给固定宽度；或者用document.fonts.ready监听字体加载完成后重新设置CSS变量。

4.3 动效降级和无障碍适配

不要忽略一部分用户对连续动画非常敏感，尤其是跑马灯、传送带这种持续运动的元素，可能引起眩晕。CSS提供了官方媒体查询：

@media (prefers-reduced-motion: reduce) { .conveyor__track { animation: none; } }

如果业务上要求保留信息展示功能，可以把动画放慢而不是完全去掉，比如animation-duration: 60s，让内容缓慢移动而不是静止成一团。

我还在项目里遇到过另一个问题：传送带无限循环，商品却只有6个，用户根本没机会看清内容。针对这种情况，我倾向于在传送带下方或侧边放暂停按钮，或者让传送带在鼠标移入时暂停。信息型内容需要让用户有停留和阅读的机会，动效只是载体，不应该成为阅读障碍。

4.4 用Performance面板定位掉帧源

如果动画已经写得符合规范，仍然感觉卡顿或掉帧，不要瞎猜，直接用DevTools的Performance面板录一段5秒左右的动画过程，观察帧率火焰图。

我通常关注两个指标：一是是否有大量红色长任务；二是动画期间是否有连续的绿色帧。长任务通常来自JS脚本同步执行，比如每帧里频繁appendChild、频繁读取offsetWidth强制同步布局；绿色帧中断则可能是主线程被样式计算占用。

定位到问题后，常见的优化砍法有：把gap换成margin可能增加样式计算量（其实现代浏览器优化得很好，gap不是问题）；减少阴影和滤镜叠加；避免在动画元素上使用backdrop-filter；限制同时存在的DOM节点数量。传送带动画一般是页面上的装饰性局部，不该成为整页性能的瓶颈。

5. 常见问题排查与避坑速查

我把这些年做传送带动画遇到的高频问题整理成一张速查表，按“现象—原因—解法”来看，排查效率会高很多。

每次动画出问题，我第一反应都是先判断问题出在“结构”还是“时机”。结构问题比如列表宽度不对、拼接间距不一致，通过检查HTML结构和计算宽度就能解决；时机问题比如资源加载、字体变化、用户交互挂起，几乎都和处理异步事件有关，需要你在写代码时预留对应的钩子。

最后分享一个控制速度的小技巧

如果传送带动画只是页面里一个不起眼的装饰，建议直接把速度做成CSS自定义属性，这样运营或产品想调速度时，你只需要暴露一个变量，不用改CSS文件：

.conveyor__track { animation-duration: var(--belt-speed, 10s); }

对应的JS更新方式：

track.style.setProperty('--belt-speed', `${newDuration}s`);

这个方案我用在很多活动页上，效果很稳定。再配合前面说的公式，把一个未知速度需求变成一个可量化的计算，你就能从“瞎填动画时长”的泥潭里彻底解放出来。

传送带动画看起来是小功能，但把它做到“无缝、流畅、可控”，需要的不是一段神奇的代码，而是一套清晰的分类思路和足够的边界意识。希望这篇文章能帮你在下次遇到传送带需求时，少走几步弯路。