Keyframes 中禁止使用 margin/padding 动画，因其触发重排、导致卡顿、margin 合并不可预测、破坏视觉连续性；应改用 transform、opacity 等合成属性实现高性能动画。
Keyframes 动画里改 margin/padding 会触发重排
直接在 @keyframes 中对 margin 或 padding 做动画，浏览器每次帧更新都必须重新计算布局（reflow），因为这两个属性会改变元素的几何尺寸和文档流位置。哪怕只是 margin-left: 0 → 20px，也迫使浏览器同步重算所有后续兄弟、父容器甚至整行块的布局关系。
常见现象：动画卡顿、掉帧、滚动变慢，尤其在中低端 Android 设备或长列表页中明显。
- 对比
transform: translateX(0) → translateX(20px)：只走合成层（compositor），不触发布局，性能高一个数量级 -
padding动画还会间接影响子元素尺寸（比如内容撑开、换行）、box-sizing行为、甚至触发父容器重绘 - 某些旧版 Safari（iOS 14 之前）对
margin动画支持不稳定，可能出现跳变或不生效
Margin 合并行为让 Keyframes 动画不可预测
垂直方向的 margin-top/margin-bottom 在块级兄弟元素间会发生外边距合并（margin collapse）。而 @keyframes 中动态修改 margin 值时，浏览器需在每一帧判断是否满足合并条件——这个逻辑不是恒定的，取决于当前 DOM 结构、是否处于 BFC、是否有 border/padding 隔断等。
结果就是：动画看起来“忽快忽慢”“间距突然变小”，尤其在动态插入/删除兄弟元素后更难调试。
立即学习“前端免费学习笔记（深入）”；
- 例如两个
.item元素用margin-bottom: 20px，动画中改为10px，但实际间距可能仍是 20px（因合并未解除） - 无法用
getComputedStyle准确读取合并后的值，DevTools 的 computed 面板显示的也不是动画运行时的真实间距
Padding 动画破坏背景与边框的视觉连续性
padding 变化会实时拉伸/压缩元素的内容区，导致背景色、渐变、边框、阴影、甚至 border-radius 的渲染出现撕裂感或闪烁——因为这些样式都绑定在元素盒模型上，而 padding 是盒模型内部可变部分。
更隐蔽的问题是：当父容器设置了 overflow: hidden，padding 缩小时可能意外暴露被裁剪的内容；放大时又可能把子元素挤出可视区，且这种溢出无法用 will-change 提前提示合成器。
- 按钮悬停加
padding？不如用transform: scale()+transition: background-color更稳 - 模态框淡入+展开效果？用
transform: scale(0.95) → scale(1)+opacity，而非改padding - 百分比
padding（如padding-top: 56.25%）绝对不能进 keyframes——它的基准是父宽，动画中父宽可能未稳定，结果错乱
替代方案：什么能安全进 Keyframes？
真正适合放进 @keyframes 的只有那些不触发重排、不依赖布局计算、能走 GPU 合成的属性：
- 优先用
transform（translate、scale、rotate、skew）和opacity - 颜色类：如
color、background-color、border-color（注意不要连带改border-width） - 滤镜类：
filter: blur()、hue-rotate()、drop-shadow() - 如果非得“模拟” padding/margin 效果，可用
transform: translate移动整个元素，或用clip-path控制可见区域（但需权衡兼容性）
真正难的不是写不出动画，而是意识到：padding 和 margin 的语义是「布局控制」，而动画的本质是「视觉表现」——把布局逻辑塞进表现层，迟早要还技术债。
