用CSS变量控制滚动位移易断层，因--offset自由增长未归一化；需JS将其限定在[0,100vw]内重置，或采用双容器错位法实现无缝滚动。
为什么用 CSS 变量控制滚动位移反而容易断层
直接用 --offset 变量驱动 transform: translateX() 时，动画到末尾会突然跳回起点——这不是 CSS 动画没写对，而是变量值本身没做周期归一化。浏览器不会自动把 100vw、200vw 映射到 0，它就老老实实按数值位移，视觉上就是“咔”一下闪回。
关键点在于：无缝 = 位移值必须在单个周期内线性变化，且终点与起点的视觉位置完全重合；而变量本身是自由增长的，必须靠计算把它“折回来”。
- 别用
calc(var(--offset) * -1)直接映射，这只会放大偏移，不解决周期问题 - 真正要的是：当
--offset走到100vw时，实际生效的位移是0；走到150vw时，生效位移是-50vw - 本质是做模运算：
mod(–offset, 100vw)，但 CSS 原生不支持mod()，得用calc()拆解
用 calc 实现模运算补偿位移
CSS 里模拟 mod(a, b) 的可靠写法是：calc(a - b * floor(a / b))，但 floor() 不可用。退而求其次，用 clamp() + 多层减法逼近，或更稳的方案：用两个副本元素错开 100vw，再用变量控制它们的相对可见性与位移。
但若坚持单元素 + 变量驱动，最简可行解是限定变量范围 + 循环重置：
立即学习“前端免费学习笔记（深入）”；
- 让 JS 控制
--offset始终保持在[0, 100vw]区间内（到达即重置为0），而不是让它一路累加 - CSS 中用
transform: translateX(calc(-1 * var(--offset)))，此时变量本身已归一化，无需额外补偿 - 如果必须允许变量超范围（比如用 CSS @property 定义动画进度），则改用双层嵌套：
translateX(calc(-1 * (var(--offset) - 100vw * floor(var(--offset) / 100vw))))—— 但注意floor()仍不可用，此式仅作示意，实际不可运行
所以务实做法：JS 主动归零，CSS 轻装上阵。
@property 定义可动画变量时的位移陷阱
当你用 @property 把 --offset 声明为 <length></length> 类型并绑定 @keyframes，动画会平滑过渡，但一旦循环次数多了，浮点误差会累积，--offset: 99.999vw 和 100.001vw 在视觉上可能差一个像素，导致衔接处露白或重叠。
- 声明时务必设
syntax: "<length>"，不能用"<number>"后自行拼vw，否则无法参与长度计算 - 动画 duration 设为刚好走完
100vw所需时间，例如10s对应速度10vw/s，避免用百分比时间 + 动态容器宽导致基准漂移 - 最关键的容错：在动画结束帧（
100%）显式写--offset: 0，而不是依赖循环自动跳转，防止浏览器插值越界
双容器错位法比纯变量更稳
真正在生产环境跑得久的无限滚动，几乎都不靠单变量算补偿，而是用两个结构相同的内容块，水平排列，左块 translateX(0)，右块 translateX(100vw)，然后用一个变量同时驱动两者反向位移：left: calc(-1 * var(--offset)); right: calc(100vw - 1 * var(--offset))。
- 当
--offset从0走到100vw，左块从0移到-100vw（完全移出），右块从100vw移到0（刚好补位） - 此时立刻把
--offset重置为0，视觉无感，DOM 也无需重排 - 这个方案完全规避了模运算和浮点误差，变量只负责“推一把”，位移逻辑由布局结构兜底
变量在这里只是触发器，不是计算器——这才是它该干的活。
