核心思路是让容器位移量精确等于所有图片总宽度且动画时长≥20s，配合white-space: nowrap和inline-block布局实现无缝滚动；响应式需JS动态计算宽度注入CSS变量，双图拼接方案须消除空白字符并固定图片宽度。
用 CSS @keyframes + animation 实现基础无缝滚动
核心思路是让图片容器在动画结束时，位置恰好回到起点，视觉上无跳变。关键不是“复制图片”，而是靠位移距离和动画时长的精确匹配。
常见错误是直接对单张图设 translateX(-100%)，结果滚动到末尾会闪回——因为位移量没覆盖整行宽度。
- 容器需设
white-space: nowrap防止图片换行 - 子元素（图片或包裹
img的span）设display: inline-block保持水平流式排列 - 动画位移量必须等于「所有图片总宽度」，不能硬写
-100%；否则多图/响应式下必断层 - 动画时长建议 ≥ 20s，太短人眼能感知加速/减速过程，破坏“无缝”感
@keyframes scroll-x {
0% { transform: translateX(0); }
100% { transform: translateX(-600px); } /* 假设所有图片加起来宽 600px */
}
.scroller {
animation: scroll-x 25s linear infinite;
white-space: nowrap;
}
.scroller img {
display: inline-block;
vertical-align: top;
}解决响应式下总宽度动态变化的问题
固定像素位移（如上面的 -600px）在缩放或换设备时立刻失效。真正在生产环境跑得稳的方案，得靠 JS 动态算宽，再注入 CSS 变量。
不要用 getBoundingClientRect().width 在动画中反复读取——触发重排，滚动卡顿。
立即学习“前端免费学习笔记（深入）”；
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 初始化时只读一次：遍历所有
img，累加offsetWidth（含 margin），存为--scroll-width - CSS 中用
transform: translateX(calc(-1 * var(--scroll-width))) - 监听
resize时**节流后**重新计算并更新变量，避免高频触发 - 如果图片异步加载（比如懒加载），需监听
load事件后重算
用两张图拼接实现纯 CSS 方案（适合静态图）
当图片数量少、布局固定，且不想引入 JS 时，可复制一倍 DOM，靠循环播放掩盖接缝。这是最轻量但限制最多的办法。
容易踩的坑是两张图之间留了空格或换行符，生成空白间隙，滚动时出现“卡顿感”。
- 两张图必须紧挨着写，中间不能有任何空白字符：
<img alt="HTML中实现图片无缝横向循环滚动的代码" ><img alt="HTML中实现图片无缝横向循环滚动的代码" >✅，<img alt="HTML中实现图片无缝横向循环滚动的代码" >\n<img alt="HTML中实现图片无缝横向循环滚动的代码" >❌ - 父容器设
font-size: 0消除 inline 元素默认间距，子元素再设回正常font-size（如果里面还有文字） - 动画位移量设为单组图片总宽（即真实内容宽），而非双倍宽——否则会滚过头
- 不适用于图片宽随屏幕变化的场景，因为位移量还是得写死
.scroller-double {
font-size: 0;
}
.scroller-double img {
display: inline-block;
width: 200px; /* 固定宽才可靠 */
}
@keyframes scroll-double {
0% { transform: translateX(0); }
100% { transform: translateX(-400px); } /* 2 张 × 200px */
}性能与兼容性注意事项
滚动区域如果内容多、图片大，transform 本身虽硬件加速，但频繁重绘仍可能掉帧。Safari 对 will-change: transform 的处理尤其敏感，乱加反而更卡。
- 给滚动容器加
contain: layout paint，告诉浏览器它内部变化不影响外部布局 - 避免在滚动容器里放
box-shadow、filter等高开销样式 - IE 完全不支持
@keyframes，如需兼容，只能降级为 JSrequestAnimationFrame+ 手动scrollLeft（但无法真正无缝） - 移动端要注意
touch-action: none阻止手势干扰，但别加在 body 上，否则影响页面整体滑动
真正的难点从来不在“怎么让它动起来”，而在于“动得足够久、足够匀、足够不被察觉”。宽度计算时机、重排抑制、以及是否接受 JS 介入，这三点决定了方案最终能不能上线。
