应优先用 transform: scale() 而非 width/height 做动画，因其不触发重排、仅重绘或合成，性能更优；但需注意缩放原点、布局占位、子元素放大、响应式基准及事件热区等限制。
为什么用 width 和 height 做动画会触发重排
每次修改 width 或 height，浏览器必须重新计算该元素及其后代的几何位置和大小（即 layout），再重绘。这个过程开销大，尤其在中低端设备或复杂 DOM 结构下，动画容易卡顿、掉帧。
而 transform: scale() 作用于合成层，只触发重绘（paint）甚至仅合成（composite），不触发布局（layout），性能好得多。
- 触发重排的属性：
width、height、top、left、margin、padding等影响盒模型的属性 - 安全用于动画的属性：
transform（含scale()、translate()、rotate()）、opacity - 若元素已设置
will-change: transform或父级有transform: translateZ(0)，更大概率被提升为独立图层，进一步减少绘制区域
用 transform: scale() 模拟尺寸变化的常见误区
直接写 scale(2) 并不等价于 width: 200%; height: 200%——因为 scale() 是以元素自身中心为原点缩放，会导致位置偏移；且缩放后元素的“占用空间”仍按原始尺寸计算（即 layout size 不变），可能引发点击区域错位、文字溢出、兄弟元素不跟随移动等问题。
- 用
transform-origin: top left可让缩放从左上角开始，避免意外位移 - 若需保持视觉尺寸与布局尺寸一致（比如卡片展开后要撑开父容器），
scale()无法替代，此时应考虑 JS 测量 +height: auto配合max-height过渡，或改用resize+overflow: hidden动画 -
scale(1.5)后，子元素字体、边框也会被放大；如只需放大容器而不放大内容，得对子元素反向缩放：transform: scale(0.666)（≈ 1/1.5）
响应式场景下 scale() 的兼容性与基准问题
scale() 的数值是相对原始尺寸的倍数，但“原始尺寸”取决于元素渲染时的计算值。如果元素宽高由百分比、flex 或 grid 决定，其初始尺寸可能随视口变化，导致相同 scale(1.2) 在不同屏幕下视觉缩放程度不一致。
立即学习“前端免费学习笔记（深入）”；
- 避免对
width: 100%的元素直接套scale()，优先用transform: scaleX()+scaleY()分离控制，或改用calc()配合固定单位（如rem）设定基准尺寸 - 旧版 Safari（iOS 12–13）对
transform动画中的小数精度较敏感，scale(1.001)可能被忽略，建议最低步进设为0.01以上 - 使用
@keyframes时，确保起始帧也声明transform: scale(1)，否则可能因未初始化而跳过过渡
何时不该用 transform 替代尺寸动画
不是所有尺寸变化都适合用 scale()。核心判断标准是：是否需要真实改变元素在文档流中的占位尺寸。
- 折叠/展开菜单：需影响兄弟元素位置 → 用
max-height+overflow: hidden更稳妥 - 模态框从按钮位置弹出：需初始定位匹配按钮尺寸 → 先用 JS 获取
getBoundingClientRect()，再用transform: translate() + scale()组合实现 - 表单输入框获得焦点时轻微放大：可用
scale(1.05)，但记得加transform-origin: center防止抖动 - 动画结束后需保持新尺寸（例如点击后永久变大）：
scale()是视觉变换，DOM 尺寸未变，后续 JS 判断offsetWidth仍是原值 —— 此时若逻辑依赖尺寸，必须同步更新 class 或内联style.width
pointer-events: none 配合伪元素覆盖，要么老实用 height 过渡 + overflow: hidden。 
