padding 变化触发重排，transform 不触发；前者影响布局API、受容器限制且易掉帧，后者由GPU合成、不改变布局值、兼容性更好。
改变 padding 会强制每帧重排，transform 不会
浏览器渲染流水线里，padding 属于盒模型尺寸属性，只要它的值一变，浏览器就必须立刻重新计算该元素的 width/height、内容流位置、兄弟/祖先元素布局——这个过程叫重排（reflow），全程跑在主线程，CPU 全包。低端安卓机一帧内反复重排，单次就耗 3–8ms，远超 16.67ms 的帧间隔底线。transform 完全不碰布局，只是挪动已有的图层纹理，由 GPU 合成线程处理，跳过 Layout 和 Paint 阶段。
padding 变化影响 offsetWidth 等 JS 布局 API，transform 不影响
如果你在动画中用 JS 读取 el.offsetWidth 或 el.getBoundingClientRect()，哪怕只读一次，浏览器也会强制同步触发重排，把动画帧直接卡住。而 transform 改变后，这些值完全不变——getBoundingClientRect() 返回的仍是原始布局框，不会引发回流。
- 常见误操作：
requestAnimationFrame里先读offsetTop，再设style.padding = '20px'→ 读写交替，必然掉帧 - 安全替代：
style.transform = 'translateY(20px)'后无需读任何布局值 - 若真需响应式 padding，用
clamp(1rem, 5vw, 2rem)+ 媒体查询，避免运行时修改
父容器 overflow: hidden 或 filter 会让 padding 动画更卡
padding 变化本身已触发重排，若元素又嵌在 overflow: hidden 容器里，或父级带 filter: blur(1px)，浏览器可能放弃图层提升，导致重排叠加重绘（repaint）——尤其是高 DPI 屏上，像素填充压力陡增。而 transform 即使在这些容器里，只要没混入非合成属性，仍能走合成管线。
- 验证方式：Chrome DevTools → Rendering → 勾选 “Layer Borders”，
padding动画元素绝不会出现绿色边框；transform元素则大概率有 - 危险组合：
transition: padding 0.3s, transform 0.3s→ 整条过渡降级为 CPU 渲染 - 绝对不要写：
* { will-change: padding; }，will-change对padding无效，还浪费内存
移动端特别容易忽略的隐性退化点
很多卡顿不是出在动画声明本身，而是动画进行中“顺手干了别的事”：比如监听 scroll 时动态改某个元素的 padding，或在 IntersectionObserver 回调里一边设 transform 一边又调 el.style.padding = ...。这两者看似独立，但只要在同一帧里发生，浏览器就会合并成一次昂贵的重排+合成。
- 真实场景：下拉刷新组件里，滚动中同时更新 loading 指示器的
padding和旋转transform→ 卡顿立刻出现 - 解法：把
padding类切换提前到滚动开始前，动画期间只动transform和opacity - 关键提醒：
transform不是万能加速器——它只保“自己不动布局”，一旦和padding、margin、width等混用，整条链路就退回 CPU
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
