根本原因是height动画强制触发重排，will-change对layout属性无效；应改用transform: scaleY()、max-height+overflow或translateY模拟伸展，并仅在必要时动态启用will-change。
绝对定位元素在 height 动画中抖动，will-change: transform 不但无效，反而可能加重问题——根本原因不是渲染没优化，而是 height 本身强制触发重排（reflow），浏览器必须反复计算布局，will-change 对 layout 属性完全无感。
为什么给 height 动画加 will-change 没用
浏览器只对「能走合成层」的属性响应 will-change，比如 transform、opacity。height 是典型的布局属性，只要它在动画中变化，每帧都会拉起完整的 layout 流程。此时加 will-change: transform 就像给一辆没油的车猛踩油门——图层提示发了，但引擎根本转不起来。
更糟的是：如果元素同时有 position: absolute 和 height: auto 或依赖内容撑高，动画过程中父容器或兄弟元素的高度可能波动，引发连锁重排，will-change 对这种跨元素影响毫无察觉。
Chrome 控制台会明确警告：Warning: will-change with non-compositable property，但很多人忽略它。
立即学习“前端免费学习笔记（深入）”；
真正该用的替代方案
要让绝对定位元素“看起来”在变高，又不抖，就得绕过 height 这个雷区：
- 用
transform: scaleY()替代height：初始化设transform: scaleY(0)，动画时改为scaleY(1)，配合transform-origin: top控制展开方向 - 若需保持内容可读性（比如 scaleY 会压缩文字），改用
max-height+overflow: hidden，但值必须是固定像素（如max-height: 200px），不能用max-height: none或百分比——否则仍会触发布局 - 最稳的解法：把内容抽成子元素，父级
position: absolute固定尺寸，子元素用transform: translateY()模拟“伸展”，例如从translateY(-100%)到translateY(0)
哪些情况可以谨慎加 will-change
只有当动画已完全基于 transform 或 opacity，且实测在 Safari iOS 15 或旧版安卓 WebView 中卡顿，才考虑临时启用：
- JS 控制动画开始前设置：
element.style.willChange = 'transform' - 动画结束回调里立刻清除：
element.style.willChange = 'auto' - 绝不写在 CSS 规则里长期挂载，比如
.dropdown { will-change: transform; }—— 图层常驻，内存泄漏风险高 - 别给整个弹窗容器加，只针对真正运动的子元素（如下拉菜单项）
容易被忽略的细节
即使你已换成 transform: scaleY()，以下写法仍会让抖动回来：
- 混用
height和scaleY：比如初始样式写height: 0，动画中只改transform，但浏览器仍要维护height的 layout 语义 - 伪元素参与高度计算：比如
::before设了display: block且未position: absolute，它会撑开父容器，间接干扰 scaleY 动画的视觉锚点 - 父容器用了
flex或grid且未设align-items: flex-start，导致 scaleY 元素在伸展时上下浮动
抖动从来不是单点故障，而是布局逻辑松动后的集体暴露。先确保动画属性干净（只用 transform/opacity），再谈 will-change；否则，加得越多，越难定位真因。
