实现无缝滚动的核心是“复制内容+位置重置”的障眼法，通过JavaScript精准控制滚动时机。1. 复制一份内容并拼接在原始内容后，形成视觉闭环；2. 使用requestanimationframe持续更新scrollleft（水平）或scrolltop（垂直）实现平滑滚动；3. 当滚动距离达到原始内容宽度或高度时，立即将滚动位置重置为0，实现无限循环；4. 优先使用transform代替left/top进行位移，减少布局重排；5. 结合will-change: transform等css属性启用硬件加速；6. 通过intersectionobserver或mouseenter/leave实现滚动暂停与恢复；7. 预加载内容避免布局跳动。水平滚动需设置white-space: nowrap并操作scrollleft或translatex，垂直滚动则操作scrolltop或translatey，二者原理一致但方向属性不同，最终均依赖JS对位置的精确控制以实现真正无缝的流畅效果。
无缝滚动，在网页上营造那种内容好像永无止境地平移、循环播放的错觉，核心思路其实就是“障眼法”——当内容滚到一头快要看不见时，迅速把它挪到另一头，或者干脆多复制一份内容接在后面，这样就永远有东西可以滚了。听起来有点像魔术，但实现起来，关键在于对时机和位置的精准控制。
要实现无缝滚动，我通常会结合JavaScript和一点点css。最直接且效果好的方法，是复制一份要滚动的内容，然后通过JS不断调整容器的
scrollLeft
或
scrollTop
，或者直接操作
transform
属性。
假设我们有一个
container
，里面装着一个
content
元素，
content
里面是我们要滚动的实际内容。
-
html结构：
-
JS核心逻辑 (以水平滚动为例):
const wrapper = document.querySelector('.scroll-wrapper'); const content = document.querySelector('.scroll-content'); // 复制一份内容，这样当原始内容滚出视线时，复制的内容可以无缝接上 const duplicatedContent = content.cloneNode(true); content.appendChild(duplicatedContent); // 将复制的内容添加到原始内容的末尾 let scrollspeed = 1; // 滚动速度，可以调整 let animationFrameId; function startScroll() { // 每次滚动一小步 wrapper.scrollLeft += scrollSpeed; // 当原始内容完全滚出视图，即滚动距离大于等于原始内容的宽度时 // 迅速将滚动位置重置到0，造成无缝循环的错觉 // 注意：这里需要的是原始内容的实际宽度，而不是包含复制内容的整个scroll-content的宽度 // 所以我们需要在复制之前记录原始宽度 const originalContentWidth = content.offsetWidth / 2; // 因为复制了一份，所以现在content是两倍宽 if (wrapper.scrollLeft >= originalContentWidth) { wrapper.scrollLeft = 0; } animationFrameId = requestAnimationFrame(startScroll); } // 鼠标悬停停止，移开继续 (可选，但常用) wrapper.addEventListener('mouseenter', () => { cancelAnimationFrame(animationFrameId); }); wrapper.addEventListener('mouseleave', () => { startScroll(); }); // 启动滚动 startScroll();这里，
requestAnimationFrame
比
setInterval
更适合做动画，因为它能更好地与浏览器刷新率同步，避免卡顿。关键在于
cloneNode(true)
复制内容，以及当
scrollLeft
达到原始内容宽度时，将其重置为0。这样，当第一份内容刚滚完，第二份内容正好出现在视口，而此时我们又把滚动位置瞬间拉回原点，就好像第二份内容变成了第一份，实现了“无限”循环。
为什么直接用CSS动画有时会“卡顿”或不连贯？
这确实是个常见的问题，很多人会觉得，既然CSS
animation
或
那么流畅，为什么不用它来做无缝滚动呢？我的经验是，纯CSS在实现“无限循环”的无缝滚动时，会遇到一个天然的障碍——它通常需要一个明确的起点和终点。
举个例子，如果你用
@keyframes
定义一个从
transform: translateX(0)
到
transform: translateX(-100%)
的动画，它会很流畅。但问题是，当动画结束时，它就停了。如果你想让它循环，你需要设置
animation-iteration-count: infinite;
。但这样一来，当动画从
-100%
跳回
0
的时候，会有一个瞬间的“闪烁”或“回弹”，因为它需要重置到起点。这个跳变就是不“无缝”的根源。
为了解决这个跳变，你可能需要复制两份甚至三份内容，然后让动画的结束点和下一份内容的开始点对齐，形成一个视觉上的闭环。比如，内容A、内容B、内容C，你复制成A、B、C、A、B、C。然后动画从第一份A的开始位置，移动到第二份A的开始位置。当动画到达这个点时，你可以瞬间把整个容器的位置重置，但这就又回到了需要JS来控制时机的问题。
所以，纯CSS动画在单次、有明确起止点的动画上表现卓越，但在需要“无限循环且视觉上绝无跳变”的场景，尤其是内容长度不固定或需要动态调整时，JS的介入几乎是不可避免的。JS能精确控制滚动位置，并在特定时刻（比如一份内容刚好滚出视野时）瞬间重置，这种“障眼法”是CSS动画难以独立完成的。
性能优化：如何让无缝滚动更流畅？
让无缝滚动真的“丝滑”，不仅仅是代码能跑起来就行，还得考虑性能。毕竟，如果滚动起来卡顿，那用户体验就差远了。
-
requestAnimationFrame
优于
setInterval
： 这是老生常谈了，但确实有效。
requestAnimationFrame
会告诉浏览器：“嘿，我这里有个动画要更新，你等下次屏幕刷新的时候再执行吧。”这样，它就能和浏览器的绘制周期同步，避免不必要的计算和重绘，从而减少掉帧。相比之下，
setInterval
是定时执行，不管浏览器忙不忙，都按时触发，容易导致动画和浏览器渲染不同步，造成卡顿。
-
避免频繁的dom操作和布局重排： 在动画过程中，尽量减少对DOM的读写操作，尤其是那些会触发浏览器布局重排（reflow）或重绘（repaint）的属性。比如，直接修改
left
或
top
属性，可能会触发布局重排，而使用
transform: translateX/Y
则通常只触发合成（composite）或重绘，性能开销小得多。这就是为什么我更倾向于使用
transform
来做位移。
-
使用CSS硬件加速： 结合
transform
，可以给要滚动的元素加上
will-change: transform;
或者
transform: translateZ(0);
（尽管后者在现代浏览器中可能不再那么必要），这能提示浏览器将该元素提升到独立的合成层，利用GPU进行渲染，大大提高动画流畅度。不过，
will-change
要谨慎使用，过度使用反而可能消耗更多内存。
-
节流（Throttling）或防抖（Debouncing）事件监听： 如果你的无缝滚动会因为用户交互（比如鼠标滚轮、触摸滑动）而暂停或改变方向，那么对这些事件的监听器进行节流或防抖处理非常重要。这能限制事件处理函数的执行频率，避免在短时间内触发大量不必要的计算。
-
内容预加载： 如果滚动的内容是图片或大量数据，确保它们在开始滚动前已经加载完毕。图片未加载完成就参与滚动，会导致布局跳动或空白，影响体验。可以监听
load
事件，或者在所有内容加载完成后再启动滚动。
-
暂停与恢复机制： 当元素不在用户视野内时，或者用户鼠标悬停时，暂停动画。这不仅能节省资源，也能提升用户体验。离开视口时暂停可以使用
IntersectionObserver
来实现。
通过这些优化，你的无缝滚动才能真正达到那种“无缝”且“流畅”的视觉效果。它不仅仅是代码逻辑的正确，更是对浏览器渲染机制和性能瓶颈的理解。
水平与垂直无缝滚动的实现异同
从核心原理上讲，水平无缝滚动和垂直无缝滚动是高度相似的，都是利用“复制内容 + 瞬间重置位置”的障眼法。然而，它们在具体实现和需要注意的细节上还是有些不同。
共同点：
- 核心逻辑： 都需要复制一份内容（或多份），将其拼接在原始内容之后，形成一个循环体。
- 动画机制： 都推荐使用
requestAnimationFrame
来驱动动画循环，以保证流畅性。
- 重置时机： 当滚动距离达到原始内容的总长度时，都需要将滚动位置瞬间重置到0。
- 性能优化： 上面提到的所有性能优化策略，如使用
transform
、硬件加速、避免布局重排等，对两种方向的滚动都适用。
不同点：
评论（0）
暂无评论