直接用width或left动态控制图片可见区域会卡顿甚至白屏，因高频触发浏览器重排；应改用transform scaleX和translateX配合ratio值、统一单位、缓存尺寸并节流更新。
直接用 width 或 left 动态控制图片可见区域，在拖动时大概率卡顿甚至白屏——这不是 JS 写错了，是浏览器被高频重排拖垮了。
为什么改 width 会卡顿甚至白屏
移动端 touchmove 每秒触发 60+ 次，每次设 element.style.width = '65%' 都会强制触发 layout（重排）。低端机掉帧，iOS Safari 直接闪白屏。这不是性能优化问题，是渲染机制硬伤。
- layout 触发成本远高于 paint 或 composite
-
width百分比依赖父容器当前 layout 尺寸，而 resize 或图片加载中，getBoundingClientRect().width可能读取不准 - 混用
px和%（比如滑块left: 200px+ 图层width: 50%）会导致响应式缩放后基准漂移
用 transform 替代 width 和 left
硬件加速、不触发 layout，且天然支持相对单位。核心是共用一个 ratio（0–1），分别驱动左右图层：
- 左侧图层（基准图）：
transform: scaleX(ratio)，并设transform-origin: left - 右侧图层（覆盖图）：
transform: translateX(calc(-100% + (100% * ratio))) - 父容器必须设
overflow: hidden，否则右侧图平移后溢出 - 所有尺寸统一用
%或calc()，禁用任何固定px值
JS 更新必须节流 + 缓存尺寸
每帧都读 offsetWidth 或写 style.width，等于主动邀请卡顿。关键不是“怎么算”，而是“怎么不触发重排”：
立即学习“前端免费学习笔记（深入）”；
- 初始化时缓存
const containerWidth = container.offsetWidth，后续只读这个值 - 在
touchmove/mousemove中用requestAnimationFrame节流更新：rafId && cancelAnimationFrame(rafId); rafId = requestAnimationFrame(updatePosition) - 计算坐标时减去容器偏移：
const x = e.touches[0].clientX - container.getBoundingClientRect().left - 限制范围：
const ratio = Math.max(0, Math.min(1, x / containerWidth)) - 移动端必须加
e.preventDefault()，否则 iOS Safari 截断事件流，滑块不动
图片加载完成前滑块错位怎么办
异步加载下，onload 前读 offsetWidth 可能为 0，导致初始 --pos 计算失效，滑块卡在左上角：
- 初始化就缓存容器宽度，不等图片加载再读
- 监听图片
load事件，再执行一次updatePosition()同步位置 - 避免在 CSS 中用
clip-path: inset(0 Xpx 0 0)动态算像素值——Safari 旧版不支持动态inset()，且单位混用易出错
最常被忽略的是：所有 transform、left、width 必须统一单位，且父容器 position: relative 不可省略——否则 absolute 子元素定位基准漂移，resize 后立刻错位。
