纯CSS实现无缝走马灯：原理、实践与避坑指南

走马灯这个效果，说大不大，说小也不小。说它不大，是因为很多项目的“公告栏”“消息条”就是一行字在那里滚，看着很简单；说它不小，是因为真要做得顺滑、不闪烁、不跳变、还能适配各种场景，纯靠CSS写和靠一套成熟方案写，差距非常大。我这两年在前端项目里接触过不少类似需求，像是后台数据大屏的跑马通知、活动页的标语滚动、还有长列表的横向轮播展示，纯CSS都能扛住大部分场景，而且相比引入一个跑马灯插件或者写一堆JS逻辑，纯CSS的方案更轻、更快、也更好维护。换句话说，如果你要做的不是那种带复杂交互（比如鼠标拖动、点击左右箭头分页）的轮播，只是想让内容自动滚动起来，那用CSS实现走马灯是完全够用的。

这篇文章我就按自己实际做过的项目经验，把纯CSS实现走马灯的几种思路、原理、坑点，还有不同场景下的选型建议都整理出来。不管你是刚接触CSS动画的新手，还是已经在项目里写过几轮轮播但总觉得不够顺滑的开发者，这篇文章都能给你一套可以直接抄作业的方案，以及一些常规文档里不会写明白的细节。

1. 需求场景与方案选型：你真的需要走马灯吗

1.1 走马灯在项目里到底解决什么问题

走马灯的经典应用场景很多，比如后台管理页顶部的“系统公告”、官网首页的“最新动态”、大屏项目里的“实时数据播报”，甚至一些页面的“合作伙伴Logo墙”也会用横向滚动来展示。这类场景有一个共同点：信息量超过容器宽度，但又不希望用户手动操作，这时候让内容自动滚动起来，是成本最低的展示方式。

我见过不少团队在做这类需求时，第一反应是去npm搜一个轮播插件，或者自己写一段setInterval配合DOM操作的逻辑。但说实话，很多走马灯需求根本不涉及分页、索引、导航按钮这些复杂交互，就是“让内容动起来”。在这种前提下，引入插件或编写大量JS不仅增加了维护成本，还可能在性能上踩坑——因为用JS频繁操作DOM的left/top属性，会引发布局抖动，尤其是在低端移动设备上，掉帧非常明显。

另一个常见的误区是用<marquee>标签。这个标签虽然能实现简单的滚动效果，但它已经被标准移除，行为在各浏览器里并不一致，而且没法做精细控制，比如无缝衔接、暂停、反向、速度调节都要靠各种hack，非常别扭。所以现在的主流方案，就是用CSS动画来驱动。

1.2 纯CSS方案相比JS方案的优势在哪里

纯CSS走马灯最大的优势是动画过程由浏览器合成器直接处理。你只需要定义一个关键帧动画，浏览器通常会把transform属性优化到合成线程执行，不会反复触发主线程的布局和绘制，因此即使长时间运行也不容易卡顿。

这里举一个具体的对比。用JS写的话，每16毫秒你就要手动更新一次元素位置（requestAnimationFrame），还要考虑时间步长、边界判断、页面隐藏时暂停等一堆边界问题；而CSS只需要写一句animation，浏览器会帮你处理时间、帧率、暂停恢复这些细节。哪怕你把动画时长设置成30秒、60秒，它也不会出现计时漂移，这一点是setInterval很难做到的。

纯CSS还有个潜在优势：无依赖、无运行时逻辑。如果你的页面还有其他重交互，减少主线程负担对整体体验是有帮助的。而且从维护角度看，纯CSS的代码量通常只有十几行到几十行，后续改速度、改方向、改样式都非常直观。

这么说并不是要否定JS方案。如果你的需求是“根据用户手势来控制滚动速度”“根据数据的长度动态调整动画时长”“点击每个滚动项要弹出不同内容”，那主逻辑肯定要放在JS里，CSS只承担渲染部分。但如果需求是“内容自动滚动，最好能无缝循环”，那我会毫不犹豫选纯CSS。

2. 从一个最简版本说起：CSS动画的基础模型

2.1 用animation + transform实现横向位移

实现走马灯最核心的动作就是“移动”。传统的写法是让元素从left: 0移动到left: -100%，但更推荐的做法是用transform: translateX()。理由后面会细说，这里先看一个最简单的demo，这种写法适合做“一次性滚动到头，然后跳回来”的简单公告。

html复制<div class="marquee">
  <span class="marquee-text">这是一条公告：系统将于今晚22点进行例行维护，请提前保存数据。</span>
</div>

css复制.marquee {
  width: 100%;
  overflow: hidden;
  white-space: nowrap;
  background: #f5f5f5;
  padding: 10px 0;
}

.marquee-text {
  display: inline-block;
  padding-left: 100%; /* 让文字从容器右侧进入 */
  animation: scroll-left 10s linear infinite;
}

@keyframes scroll-left {
  0% {
    transform: translateX(0);
  }
  100% {
    transform: translateX(-100%);
  }
}

这段代码的原理很简单：padding-left: 100%让文字一开始就在容器右侧之外，然后动画把它从右往左移动。因为文字是inline-block，它自己的宽度就是文字内容的宽度，translateX(-100%)在这里位移的是文字自身的宽度，刚好让文字完全移出左侧。

这里需要特别留意一点：translateX的百分比是相对于元素自身宽度，而不是容器宽度。很多新手在这里容易踩坑，以为-100%就是把整个容器宽度移出去，结果发现文字位移的距离不对，滚动速度看起来忽快忽慢。

2.2 为什么用transform而不是left/top

如果你以前写过利用left属性做位移的动画，会发现单纯改left也能实现同样的效果，代码可能长这样：

css复制.marquee-text {
  position: relative;
  left: 0;
  animation: move-left 10s linear infinite;
}

@keyframes move-left {
  to {
    left: -100%;
  }
}

跑起来看效果差别不大，但浏览器内部的性能差异非常明显。left属于布局属性，修改它会触发元素及其周围元素的重新布局（Layout），然后是绘制（Paint），最后才算合成（Composite）。而transform是合成属性，浏览器会在合成阶段直接处理它，如果元素本身没有触发重新布局，整个动画过程可以做到几乎不占用主线程的布局时间。

用生活一点的话说：left滚动就像你推着一辆购物车在超市走，每走一步都要重新规划路线、确认货架位置；transform滚动更像是跑步机上的传送带，机器自己动，你只管站上去就行。两者最终都让人移动了一段距离，但底层的“工作量”完全不同。

在需要长时间运行的走马灯动画里，这个差异会被放大。尤其是页面里同时有好几条走马灯的时候，用left的页面很容易出现明显的CPU占用上升和掉帧，改用transform之后会顺滑很多。

2.3 最简版本的不足：滚动不连贯

有了上面的基础代码，你可能会发现一个问题：当文字滚出去之后，容器会先空一会儿，然后文字从右边再次出现。这放在简单的公告场景里还能接受，但如果你想让多条消息首尾相连、循环不断，这种“跳变”就会非常明显。

原因是动画每次循环结束时，元素位置会从translateX(-100%)瞬间跳回translateX(0)，而0%位置对应的内容是文字开头。也就是说，整个滚动过程实际上只有一个“从头滚到尾”的流程，并没有做到真正意义上的无缝循环。

要解决这个问题，就需要引入无缝滚动的核心思路：让内容“看起来”永远滚不完。

3. 无缝滚动原理与实现：复制内容与50%位移

3.1 核心原理：利用内容复制制造“假循环”

无缝滚动的思路其实很朴素：把内容复制成两份，第一份滚动结束后，第二份正好补到第一份的位置上，而用户看的是两份连续的内容，感知不到“跳变”。

用图来表示的话，初始状态是：

code复制| 内容A | 内容B |（两者相同）

动画让整个容器向右移动，移动距离是内容宽度的一半。当移动量达到一半时：

code复制| 内容B | 内容A |（第二份出现在原本第一份的位置）

此时如果瞬间把位移归零，用户看到的画面其实没有任何变化，因为“内容B”已经出现在“内容A”原来的视觉位置上了。这就是所谓的“无缝循环”。

这里的核心就是：位移量 = 内容总宽度的一半，也就是复制后总宽度的50%。因为两份内容完全一样，所以无论你是从50%跳回0%，还是从0%跳到50%，视觉上都是相同的画面。

3.2 一个可直接复用的无缝滚动实现

下面这段代码是我在项目里用过很多次的基础版本，结构简单，适合“多条目横向滚动”的场景。

html复制<div class="marquee-wrap">
  <div class="marquee-track">
    <div class="marquee-content">
      <span>消息1：系统维护通知</span>
      <span>消息2：新版本上线</span>
      <span>消息3：运营活动开启</span>
    </div>
    <!-- 复制一份完全相同的内容 -->
    <div class="marquee-content">
      <span>消息1：系统维护通知</span>
      <span>消息2：新版本上线</span>
      <span>消息3：运营活动开启</span>
    </div>
  </div>
</div>

css复制.marquee-wrap {
  width: 100%;
  overflow: hidden;
  background: #fafafa;
  padding: 12px 0;
  border: 1px solid #eee;
}

.marquee-track {
  display: flex;
  width: max-content; /* 关键：让轨道宽度跟随内容，而不是占满容器 */
  animation: marquee-scroll 20s linear infinite;
}

.marquee-content {
  display: flex;
  flex-shrink: 0;
  padding-right: 20px; /* 两份内容之间的间距，你也可以用gap */
}

.marquee-content span {
  margin-right: 40px;
  white-space: nowrap;
  font-size: 14px;
  color: #333;
}

@keyframes marquee-scroll {
  from {
    transform: translateX(0);
  }
  to {
    transform: translateX(-50%);
  }
}

注意几个关键点：

• width: max-content很重要。如果没有它，flex容器默认会占满父级宽度，导致两条内容被压缩到一行内，动画位移50%的方向和距离都不对。
• flex-shrink: 0用来防止子项被压缩，保证内容保持原始宽度。
• 两份内容之间的间距要统一处理。我用的是padding-right加margin-right的组合，你完全可以换成gap，但要注意：gap只作用于flex子项之间，不会在轨道末尾额外加宽，所以更推荐用gap: 0 40px，同时去掉span的margin-right，这样计算间距更不容易出错。

3.3 位移距离为什么是50%，而不是内容的宽度

很多人在写无缝滚动时会想：既然内容被复制成了两份，那我让整个轨道从translateX(0)移动到translateX(-100%)，不就把第一份完全移出去了吗？这种想法没错，但如果你把第二份放进去，整个轨道宽度是原来内容的2倍，位移100%等于把两份内容都移出去了，此时画面里看到的其实是容器左侧的空白，而第二份已经在视口外了，滚动到末尾还是会跳变。

正确的做法是：位移到轨道总宽度的50%，也就是刚好把第一份完全移出视口，让第二份顶到第一份原来的位置。这时候你在动画的“结束帧”和“起始帧”看到的是同一幅画面，所以循环切换不会暴露破绽。

这里有一个常见误区：如果你的两份内容之间有间距，而且这个间距不一致（比如第一份结尾有40px间距，第二份结尾没留），那动画在循环点会有微小的跳动。最稳妥的做法是让两份内容结构完全一致，间距也完全一致，这样无论滚到哪一帧，画面都是均匀的。

3.4 内容宽度不固定时怎么处理

上面的实现里，内容宽度是由内容本身决定的。但在实际项目中，消息条数可能是动态的，可能今天3条、明天5条，甚至每条消息的长度都不同。这种情况下，如果动画时长是固定的，滚动速度就会忽快忽慢，看起来很不专业。

解决思路有两种。

第一种是动态计算动画时长。用JS读取轨道宽度和视口宽度，然后按“速度恒定”的原则计算出合适的动画时长，比如时长 = 轨道宽度 / 期望速度。这个方案虽然引入了JS，但逻辑非常轻，只负责计算一个CSS变量，动画本身还是CSS驱动。

javascript复制const track = document.querySelector('.marquee-track');
const speed = 100; // 期望滚动速度，单位 px/s
const distance = track.scrollWidth / 2;
track.style.setProperty('--duration', `${distance / speed}s`);

CSS里配合使用：

css复制.marquee-track {
  width: max-content;
  animation: marquee-scroll var(--duration, 20s) linear infinite;
}

第二种是固定速度的感觉，用animation-duration配合内容条数做一个粗略配置。比如8条消息用20秒，12条消息用30秒，适合要求不高的场景。这种写法不做精确计算，但胜在零JS，代码简洁。

我个人在实际项目中更推荐第一种方式，因为它的体验更稳定：无论消息多长、条数多少，滚动速度始终一致，观众看起来会舒服很多。

4. 交互增强与边界场景：让走马灯更可控、更专业

4.1 hover暂停、点击跳转与方向控制

很多走马灯需求会要求“鼠标悬停时暂停滚动”，方便用户阅读内容。纯CSS也能实现，只需一行：

css复制.marquee-wrap:hover .marquee-track {
  animation-play-state: paused;
}

我建议你始终加上这个规则，因为如果不加，用户悬停时文字还在动，想看清楚内容非常费劲。在项目验收时，这条细节经常会被提出来。

点击跳转的处理稍微复杂一点。如果每条消息都对应一个链接，可以把span替换成a标签，加上onclick事件或者href跳转。但要注意：不要给轨道整体加点击事件，然后通过event.target去判断谁被点击，因为滚动过程中，用户点击的可能是复制出来的第二份内容，如果没有给两份内容做统一的标识，很容易出现“点第一条消息和点第三条消息效果一样”的诡异问题。最简单的做法就是使用a标签并给每条消息一个独立的链接，复制出来的内容也同样带着链接，这样点击任何一份都能正常跳转。

方向控制也很简单。CSS动画默认从左往右移动（translateX从0到-50%），如果你想实现“从右往左反向滚动”，只需要把关键帧改成：

css复制@keyframes marquee-scroll-reverse {
  from {
    transform: translateX(-50%);
  }
  to {
    transform: translateX(0);
  }
}

或者直接在动画里用animation-direction: reverse。用reverse的好处是你不需要重写一套关键帧，尤其当你有多个动画时，代码复用度更高。

4.2 小屏适配与容器宽度问题

走马灯在移动端最大的坑是：字体大小变化导致内容宽度变化，但动画位移还是写死的50%。 因为CSS里的translateX(-50%)是相对于轨道总宽度的，所以只要轨道宽度正确，移动端的50%依然会精确落在循环点上。真正需要担心的是轨道宽度是否被正确撑开。

开发中，我遇到过display: flex的轨道在某些安卓WebView下没有撑满内容宽度的情况。解决办法是给.marquee-track再加一行min-width: max-content，或者干脆把轨道设置成display: inline-flex。这两种方式都能保证轨道宽度完全由内容决定。

另外，容器横向滚动条也是一个常见问题。虽然.marquee-wrap设置了overflow: hidden，但如果内部元素的宽度超过容器，部分浏览器在某些特殊场景下（比如字体加载后）依然会短暂出现滚动条。稳妥的做法是再加一条overscroll-behavior: none，对移动端手感也有帮助。

4.3 性能优化与无障碍考虑

提到性能，will-change: transform是一个经常被提及的属性。它的作用是提前告诉浏览器“这个元素会有变换动画”，让浏览器为它建立合成层，减少动画过程中的重绘消耗。

css复制.marquee-track {
  will-change: transform;
}

但这里有个反直觉的点：will-change并不是设了就最好。如果对很多元素同时设置will-change，浏览器的内存占用会上升，反而可能拖慢整体性能。我的经验是：走马灯轨道只有一两个的时候可以加，如果页面上同时有十几条走马灯，建议不加，因为每条轨道都建一个合成层，对移动端GPU压力不小。

无障碍方面，我真的希望每个做走马灯的同学都能重视一下。滚动动画对普通人来说是“动态感”，对某些视觉敏感用户或认知障碍用户来说，可能就是“干扰源”。好在CSS标准里提供了一个媒体查询：

css复制@media (prefers-reduced-motion: reduce) {
  .marquee-track {
    animation: none;
  }
  .marquee-content {
    display: flex;
    flex-wrap: wrap;
  }
}

这段代码的意思是：如果用户在系统设置里开启了“减弱动态效果”，走马灯就不再自动滚动，而是显示为可换行的普通文本。这个改动成本极低，但能显著提升部分用户的使用体验，在无障碍测评中也会是一个加分项。

5. 常见问题与排查技巧实录

5.1 滚动不连贯、循环点跳变

这是最常遇到的问题。如果动画在循环点有肉眼可见的跳变，优先检查以下几点：

1. 两份内容是否完全一致（包括结构、间距、子元素宽度）。
2. 动画位移是否为-50%，有没有写成-100%。
3. 轨道宽度是否等于两份内容宽度之和，有没有被flex压缩。

我在调试这类问题时，习惯先把animation去掉，手动把轨道拖到translateX(-50%)查看画面的连续性。这样能快速判断是动画参数的问题，还是内容结构的问题。

5.2 走马灯区域出现空白或高度塌陷

出现空白，大概率是内容没有撑开容器高度，比如.marquee-track使用了绝对定位，或者span都是inline元素没有高度。解决方式是让轨道内的内容有一个明确的“内容块”，可以给.marquee-content设置一个高度，或者让内容里的元素使用flex布局。

如果空白出现在动画即将结束时，通常是位移距离超过了实际内容宽度，也就是第二条内容已经完全滚出视口。这时需要重新检查“轨道总宽度”和“位移50%”是否匹配。

5.3 hover暂停时动画闪烁

我之前在项目里碰到过hover暂停时画面闪一下的问题。排查后发现原因是：暂停状态下will-change: transform和animation-play-state: paused在部分浏览器里触发了重绘。解决办法是去掉will-change，或者把animation-play-state: paused改成控制transform的过渡。

css复制.marquee-wrap:hover .marquee-track {
  animation-play-state: paused;
}

如果还是闪烁，可以尝试把hover规则放在更精确的选择器上，比如.marquee-wrap.interactive:hover .marquee-track，避免命中过多嵌套元素。

5.4 字体加载完成后内容变宽导致间距跳动

这个问题在网页中非常隐蔽。如果走马灯里的文字用了非系统字体，字体加载前后文字的宽度可能变化，导致第一条内容已经滚出视口时，第二条内容的起点和第一条内容的终点之间出现几像素的间距差，用户会看到一次轻微的“抖动”。

规避方法有两种：一是字体声明里设置font-display: swap，这样文字先用系统字体渲染，等自定义字体加载后再切换，避免容器宽度突变；二是给.marquee-content设置一个固定的min-width，比如按最长的消息长度估算出一个最小值，保证两份内容在滚动中不会因为字体变化而重新布局。

5.5 移动端出现卡顿与电量消耗异常

移动端的WebView性能差异很大。低端安卓机上如果走马灯动画卡顿，首先检查是不是动画过程中触发了布局。常见的触发点是子元素有margin变化、padding变化，或者width: auto参与动画。把这些属性全部改为固定值，并确保动画只作用于transform和opacity，通常会有明显改善。

如果页面里有多条走马灯同时滚动，建议把它们的动画时长设置成不同的值，避免所有动画在同一时刻触发重绘，从而降低移动端GPU压力。

最后再说一个我踩过好多次的坑。很多同学在做走马灯时，会把内容直接写在HTML里，万一后续要动态更新消息，就不得不用JS去重新拼DOM。实际上你完全可以把每条消息渲染成独立的a或者span，然后通过CSS控制轨道动画。如果频道运营希望后续能快速改内容，那就只需替换数据源，不需要动动画代码。把“内容”和“动画”解耦，代码的可维护性会提升很多。