应使用transform: scale()配合transition实现平滑缩放，避免width/height触发重排；transition须写在默认状态，transform-origin控制缩放中心，移动端需兼顾touch交互与可访问性。
直接用 transform: scale() 配合 transition 或 @keyframes，别碰 width/height——后者会触发重排、圆角变形、动画卡顿，且不是真缩放。
用 transition 实现 hover 缩小（最常用）
适合按钮、卡片、图标等需要交互反馈的场景。关键点是：必须设 transition 在非 :hover 状态上，否则首次悬停无动画；transform-origin 决定缩放中心，默认是元素中心，但文字类常需设为 top left 避免位移抖动。
-
transition必须写在基础样式里，比如.btn { transition: transform 0.25s ease-out; }，不能只写在:hover里 - 缩小到 80% 就写
transform: scale(0.8)，不是scale(80%)（后者无效） - 如果文字缩小后边缘轻微溢出容器，加
overflow: hidden+line-height对齐更稳 - 移动端要慎用 hover —— iOS Safari 在非可点击元素上不触发 :hover，建议同时加
touchstart类或改用 click 触发
用 @keyframes 做一次性 zoomOut 动画（如退出提示）
适用于模态框关闭、通知收起、元素淡出等明确起止状态的动效。注意：animation-fill-mode: forwards 必须加，否则动画播完立刻回弹到原始尺寸。
- 定义动画：
@keyframes zoomOut { from { transform: scale(1); opacity: 1; } to { transform: scale(0.7); opacity: 0; } } - 应用时写全：
animation: zoomOut 0.3s ease-in forwards;，漏掉forwards就白写了 - 不要给同一个元素同时设
transition和animation，CSS 会优先用 animation，transition 可能被忽略 - 若需手动控制播放（比如点击触发），用 JS 切换 class 比直接操作
style.animation更可靠
scale() 失效的三个高频原因
transform: scale() 看似简单，但实际项目里经常“点了没反应”或“缩了但位置飘了”，多数卡在这几个点上：
立即学习“前端免费学习笔记（深入）”；
- 父容器有
overflow: hidden且子元素缩放后超出边界 —— 解决办法是给父容器加transform: translateZ(0)或will-change: transform强制 GPU 加速，让裁剪逻辑正确生效 - 元素本身用了
position: absolute且未设top/left，缩放后坐标系偏移 —— 应显式设置transform-origin: 0 0或对应像素值 - JS 动态设置时写成
el.style.transform = 'scale(0.8)'覆盖了已有 rotate/translate —— 正确做法是用el.style.transform = 'rotate(10deg) scale(0.8)'合并，或用 CSS 自定义属性间接控制
移动端双指缩放与 CSS zoom 冲突怎么办
原生双指缩放（user-scalable=yes）和 CSS transform: scale() 是两套机制，混用会导致手势失效、缩放中心错乱、甚至页面卡死。真要支持手势缩放，就别自己写 scale() 动画；想做 CSS 动画，就关掉原生缩放。
- 禁用原生缩放：在
<meta name="viewport">里加user-scalable=no，但注意这会让低视力用户无法放大，WCAG 不推荐 - 若必须保留可访问缩放，CSS 动画只作用于局部容器（如图片画廊），并确保该容器
touch-action: manipulation，避免手势冲突 -
zoom这个 CSS 属性（非 transform）已废弃，Chrome/Firefox 不支持，Safari 仅部分支持且不触发动画，一律不用
真正难的不是写对那一行 scale(0.8)，而是缩放后元素的定位、文字渲染清晰度、与其他 transform 操作的叠加顺序，还有 touch 设备上那毫秒级的手势判定时机 —— 这些细节不验证到真机，光看桌面预览永远发现不了。
