高刷新率屏幕CSS transition抖动源于浏览器合成层调度跟不上帧节奏，关键在于只用transform和opacity做过渡、避免重排属性及亚像素渲染，并显式触发GPU合成层。
高刷新率屏幕（120Hz/144Hz）上 CSS transition 抖动，根本不是“屏幕太灵敏”，而是浏览器合成层调度跟不上帧节奏——尤其当过渡属性触发重排或亚像素渲染时，掉帧会直接暴露为肉眼可见的跳变。
为什么高刷屏抖动更明显
60Hz 屏幕每 16.7ms 渲染一帧，人眼对微小错位不敏感；120Hz 缩短到 8.3ms，同一段动画若因重排卡顿 1–2 帧，就会变成明显“抽搐”。关键问题不在帧率本身，而在 transition 是否全程走合成层：
-
left、top、margin等属性在高刷下重排开销翻倍，极易掉帧 -
transform: translateX(10.5px)这类非整数位移，在部分安卓 WebView 或旧版 Safari 中触发亚像素模糊+边缘跳变，高刷屏会放大这种不稳定 -
transition: all 0.3s会偷偷给border、padding加过渡，这些属性无法合成，强制拉低整条动画链的帧率
必须只用 transform 和 opacity 做过渡
这两者是唯一被所有现代浏览器标记为“可合成”的 CSS 属性，不触发布局（reflow）和绘制（paint），只走 GPU 合成管线：
- 把
left: 100px改成transform: translateX(100px)，并确保元素有position: relative或absolute - 用
opacity: 0替代visibility: hidden或display: none—— 后两者无法插值，一设即变 - 避免在同一个
@keyframes或 transition 链里混用width、height、background-color，哪怕只写一次，整条链都会退回低效路径
强制启用稳定合成层的实操写法
光写 transform 不代表它进了合成层。需要显式触发更可靠的 GPU 路径：
立即学习“前端免费学习笔记（深入）”；
- 单个动画元素加
backface-visibility: hidden：不改变视觉，但绕过某些 WebView 的亚像素 bug - 兜底用
transform: translateZ(0)：极老环境有效，但别和will-change混用 -
will-change: transform必须动态设置：JS 动画开始前加element.style.willChange = 'transform'，结束后立刻设回'auto'，否则长期占用 GPU 内存
Isotope 或其他 JS 布局库抖动的特殊处理
这类库内部依赖 transform: translate() 精确控制位置，如果你在 .item 上写了全局 transition: all .3s，浏览器会试图同时过渡 margin、opacity、甚至 transform 自身，导致 Isotope 的位移指令被干扰：
- 立刻删掉
.item { transition: all .3s; }这类通用声明 - 只在真正需要动画的子元素上加过渡，比如
.item img { transition: opacity .2s; } - 检查是否残留了
margin-left: 20px这类 layout 属性——哪怕没在动画里改它，只要存在，就可能让合成器放弃优化
最容易被忽略的是：哪怕 keyframes 全用 transform，只要 CSS 文件里还有一行未注释的 top: 10px，整个动画链就失效。高刷屏会立刻暴露这个细节。
