唯一能稳定消除移动端拉出锯齿与掉帧的组合是transform: translateX()搭配will-change: transform和backface-visibility: hidden；因合成层未激活导致iOS Safari等浏览器边缘发虚、动画掉帧，需满足三条件启用硬件加速并正确管理图层生命周期。
用 transform: translateX() 搭配 will-change: transform 和 backface-visibility: hidden，是目前唯一能稳定消除移动端拉出时锯齿与掉帧的组合。单靠 translateX() 不够，iOS Safari 和旧版 Android WebView 会因合成层未激活或渲染管线干扰，导致边缘发虚、动画跳帧。
为什么边缘发虚、动画掉帧不是“样式没写对”，而是合成层没建好
浏览器只有把元素提升到独立合成层（compositing layer），GPU 才会接管位移渲染。否则 translateX() 仍走主线程绘制，尤其在含文字、图标、阴影的抽屉里，边缘抗锯齿失效、帧率跌破 45fps 是常态。常见误判是改 cubic-bezier 或加 opacity，但这些不解决根本——合成层缺失。
必须满足三个条件才真正启用硬件加速：
-
will-change: transform或transform: translateZ(0.001px)（后者兼容微信 7.0.20 以下） - 抽屉容器不能同时设
opacity、filter或mask，它们会降级合成层 - 内容区加
backface-visibility: hidden，防止 iOS Safari 渲染器重叠采样导致文字毛边
移动端 touch 拖拽时位移跟手差、松手后惯性不足
这不是 JS 写得慢，而是每次 touchmove 直接改 style.transform 触发了同步样式计算，阻塞了合成器。用户一拖就“滞后”，松手后动画卡在半路。
正确做法是用 CSS 变量驱动位移，并配合 requestAnimationFrame 批量更新：
- HTML 中给抽屉容器设
style="transform: translateX(var(--tx, -100%));" - JS 里只在
requestAnimationFrame回调中更新el.style.setProperty('--tx', `${x}px`) - 避免用
touches[0].clientX算绝对位置，改用touches[0].screenX防止横竖屏切换时坐标偏移
安卓 WebView / 微信内置浏览器中 translateX(-100%) 失效或露白边
-100% 在部分低版本 WebView 里按父容器宽度计算，而抽屉自身宽是 280px，结果只左移了 200px，右边漏出白边；更糟的是，100vw 包含滚动条宽度，有竖向滚动时左侧会露缝。
实操建议统一用像素基准：
- 抽屉容器显式设
width: 280px（别用%或vw） - 隐藏态写死
transform: translateX(-280px)，展开态为translateX(0) - 收起后立刻加
visibility: hidden+pointer-events: none，防止残留点击穿透
真正难的不是“怎么动起来”，而是确保每次打开前都重建合成层、每次关闭后都清空 transform 值并释放图层。很多项目在真机上反复出现“第一次滑顺、第二次卡顿”，问题就出在 will-change 没及时设回 auto，或者关闭时只删 class 没重置内联样式。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
