应优先使用 transform 实现 hover 动画，因其不触发重排，仅走合成层；如用 scale() 替代 width/height 放大，translate() 替代 margin 移动，并明确 transition 属性。
hover 时用 width/height/margin 改变元素尺寸会触发重排
直接在 :hover 中修改 width、height、margin 或 padding，浏览器必须重新计算元素位置和周围布局（即 layout / reflow），导致卡顿、抖动，尤其在列表或网格中明显。这不是 bug，是 CSS 渲染机制决定的。
解决思路是：把“视觉变化”和“布局计算”解耦——只动 transform，它不触发布局重算，只走合成层（compositor），性能好得多。
transform scale 实现放大但不挤占空间
比如按钮悬停放大，别写 width: 120px; height: 40px;，改用 transform: scale(1.1);。注意：scale() 以元素中心为原点缩放，不会影响文档流，父容器和兄弟元素完全感知不到变化。
-
transform: scale(1.1)等价于视觉上变大 10%，但布局尺寸仍是原始值 - 如果想让放大后文字也更清晰，加
transform-origin: center（默认就是 center，可省略） - 慎用
scaleX/scaleY单向缩放，容易造成文字压扁或拉伸失真
button {
padding: 8px 16px;
transition: transform 0.2s ease;
}
button:hover {
transform: scale(1.1);
}
用 transform translate 替代 margin 移动
想让 hover 时元素“浮起”或“右移”，别碰 margin-top: -5px 或 margin-left: 10px，它们会推挤邻近元素。换成 transform: translateY(-5px) 或 translateX(10px)，移动纯属视觉位移，不影响布局流。
立即学习“前端免费学习笔记（深入）”；
-
translate()不改变元素的几何盒模型（bounding box），所以position: relative的偏移效果类似，但更轻量 - 若同时需要缩放 + 平移，写成
transform: scale(1.05) translateY(-3px)，顺序无关（浏览器会合并矩阵） - 避免在
transform中混用top/left，那又回到布局计算路径了
transition 要明确指定 transform 属性
别写 transition: all 0.3s —— 它会让所有可动画属性一起动，包括可能触发重排的 color、background（虽然不重排，但没必要全开），还可能掩盖问题。只交由 transform 和 opacity 承担动画职责最稳妥。
- 正确写法：
transition: transform 0.25s cubic-bezier(0.25, 0.46, 0.45, 0.94), opacity 0.25s - 如果用了
will-change: transform，仅限复杂动画场景且已确认必要；日常 hover 不必加，反而可能引发额外内存开销 - 移动端要注意：部分老安卓 WebView 对
transform的硬件加速支持不稳定，建议加transform: translateZ(0)强制开启合成层（现代环境基本不需要）
真正难的不是写出 transform，而是意识到哪些样式改动正在悄悄拖慢页面——尤其是当 hover 效果看起来“差不多”时，重排抖动往往被忽略到上线后才暴露。
