双份内容+负延迟+硬件加速是CSS无缝滚动的三大核心条件：复制图片确保终点精准对齐第二组起点，负延迟消除首帧卡顿，will-change/translateZ(0)触发GPU加速防掉帧。
直接用 @keyframes + translateX(-100%) 做循环滚动，90% 的人会在 Safari 或低端安卓 WebView 里看到明显闪动——这不是 CSS 写错了，是动画逻辑没对齐浏览器渲染帧。真正稳的方案必须满足三个条件：双份内容、位移终点精准对齐第二组起点、首帧视觉不跳。负延迟不是“锦上添花”，而是补上第一帧错位的关键一环。
为什么 translateX(-100%) 会闪，而 -50% 不会？
translateX(-100%) 的 100% 指的是子元素自身宽度，不是容器宽。单组内容滚动到末尾时，视口右侧必然留白；动画重置瞬间，浏览器来不及把第一帧对准第二组开头，就露底或撕裂。
用双份内容（如原内容 A B C → DOM 里写成 A B C A B C），再设动画终点为 translateX(-50%)，本质是让动画走一半距离，就把第二组完整推入视口。此时第一组刚好完全退出，第二组起始位置与第一组原始起点视觉重合——断点被物理长度覆盖了。
- 必须确保两组总宽度 ≥ 容器宽度 × 2，否则还没滚到 50% 就露底
-
white-space: nowrap和display: inline-block（或flex）缺一不可，否则换行/间隙会让实际宽度失真 - 别用
margin或padding手动调间隙，不同字体下不稳定
负延迟（animation-delay: -N s）到底在解决什么？
动画默认从 0% 开始，但 DOM 渲染完后，内容初始位置是静止在 translateX(0) 的。用户第一眼看到的不是“滚动中”，而是“刚要动”的卡顿帧。负延迟让浏览器直接跳到动画中间某一帧渲染，模拟出“已经滚动了一段时间”的自然状态。
立即学习“前端免费学习笔记（深入）”；
- 若动画总时长是
40s，想让它从第12s的状态开始显示，就写animation-delay: -12s - 负延迟值不能 ≥ 动画时长，否则行为未定义（多数浏览器会取模，但结果不可控）
- 务必搭配
animation-fill-mode: backwards，否则延迟期间元素样式会回退到未动画状态
Safari 和移动端常见卡顿怎么破？
Safari 对 transform + animation 复合渲染有已知缺陷，尤其当文字含阴影、字体平滑开启、或使用复杂 cubic-bezier() 时，容易掉帧或首帧抖动。
- 给滚动容器加
will-change: transform或transform: translateZ(0)，强制启用硬件加速层 - 禁用
-webkit-font-smoothing: antialiased，改用subpixel-antialiased - 避免在滚动元素上用
text-shadow、filter或backdrop-filter，这些会破坏图层合并 - 响应式场景下，font-size 变化会导致文字宽度变，但 CSS 中的
100%仍按旧尺寸计算——此时必须用 JS 重设animation-duration和animation-delay
最易被忽略的一点：DOM 必须真实存在两份内容，不能靠伪元素、JS 动态插入或 visibility 隐藏来“模拟”。浏览器动画引擎只读取当前渲染树中的节点宽度和位置，任何间接手段都会导致位移计算失准。双份内容+负延迟+硬件加速，三者缺一不可。
