最稳的流畅轮播方案是用 transform: translateX() + requestAnimationFrame 替代 setInterval + transition，因其能精准控制动画时序、支持中断重置、避免状态冲突，并配合 touchend 校准、GPU 加速和原子化状态更新。
用 transform: translateX() + requestAnimationFrame 替代 setInterval + transition，是当前最稳的流畅方案。单纯靠 CSS transition 配合定时器，在手动干预后极易出现“抽搐”或“提前切入”，本质是动画时序失控。
为什么 setInterval + transition 容易卡顿
自动轮播节奏（比如每 3s 一次）和 CSS 过渡时长（比如 transition: transform 0.4s ease）是两套独立系统。用户点一下“下一张”，JS 立刻改了 transform 值，浏览器开始执行 0.4s 动画；但原定 3s 后的 setInterval 回调仍会准时触发，强行覆盖中间状态——结果就是画面跳变、回弹、或两张图同时露一半。
- 定时器不感知动画是否结束，
clearInterval也拦不住已排队的回调 -
transition在 Safari 上对动态写style.transform响应不稳定，尤其快速连点时 - 无法做缓动插值，所有位移都是线性硬切，缺乏物理感
用 requestAnimationFrame 控制每一帧位移
把动画控制权交还给浏览器渲染循环，自己算进度、插值、中断和重置，才能真正顺滑。核心不是“换得快”，而是“换得准”。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 切换开始时记录
startTime = performance.now()、目标位置、总时长（如 300ms） - 在
requestAnimationFrame回调里计算当前进度：progress = Math.min((now - startTime) / duration, 1) - 用缓动函数（如
cubic-bezier(0.25, 0.46, 0.45, 0.94)）处理progress，再算实时translateX - 只要新操作到来（如用户又拖拽），立刻退出旧 raf 循环，启动新动画，无堆叠
移动端滑动必须加 touchend 校准逻辑
手指松开那一刻，不能只看偏移量就切图——得判断是“微调回弹”还是“有效切换”。否则松手停在两张图中间，视觉和状态都错位。
立即学习“前端免费学习笔记（深入）”；
-
touchstart记下startX；touchmove中实时更新临时位移，并调用e.preventDefault() -
touchend时计算总偏移offset = currentX - startX，绝对值小于 30px 就回弹到当前图 - 若
Math.abs(offset) > slideWidth * 0.3，才触发切换，并强制将currentIndex设为对应索引 - 校准后立刻调用
raf动画滚动到位，避免松手后“悬停半路”
容易被忽略的硬件加速与状态锁
再好的动画逻辑，一旦触发重排或状态不同步，就前功尽弃。这两个点常被跳过，但直接影响是否“真流畅”。
- 轮播容器必须加
transform: translateZ(0)或will-change: transform，启用 GPU 加速，防止 iOS 滚动卡顿 - 加
isTransitioning布尔锁：动画进行中，禁止响应任何点击/触摸切换，避免状态覆盖 - 所有关联状态（
currentIndex、DOM 的translateX、指示点active类）必须在同一个函数内原子更新，不拆成多个setTimeout - 图片宽度务必用
el.getBoundingClientRect().width动态读取，别硬写300px—— 响应式布局下它随时会变
