根本原因是visibility属性不可被transition动画化，浏览器空等过渡时间后才执行隐藏，导致卡顿；应改用transform+will-change实现硬件加速的丝滑折叠。
为什么 visibility + transition 会导致折叠卡顿
根本原因不是动画本身慢，而是 visibility 属性根本不能被 transition 动画化。当你写 transition: all .5s ease 并配合 visibility: hidden 切换时，浏览器会“假装”要过渡这个属性——但它做不到，于是整个 .5 秒周期都在空等，直到时间结束才真正隐藏元素。视觉上就是“点了没反应，停半秒才消失”。
常见错误现象包括：
- 点击汉堡图标后导航栏悬停约 500ms 才消失
- 折叠/展开过程中有明显“粘滞感”，尤其在中低端安卓设备上
- JS 已执行
classList.toggle('open')，但 DOM 渲染滞后
哪些 CSS 属性能真正触发硬件加速
只有少数属性能被 GPU 加速，且必须满足“不触发布局（reflow）和重绘（repaint）”的前提。真正可靠的是：
-
transform（尤其是translateX、scaleY）——浏览器会为其创建独立合成层 -
opacity—— 不影响布局，可直接由 GPU 处理 -
filter（如blur(0)）——部分场景可用，但兼容性略弱
以下属性**不能**硬件加速，且极易引发卡顿：
-
width、height、left、top—— 触发重排 -
background-color、border—— 触发重绘 -
visibility、display—— 不可动画，transition对其无效
如何用 transform + will-change 实现丝滑折叠
用 transform 替代位置或尺寸变化，是解决卡顿最直接有效的方式。关键不是加动画，而是让浏览器提前知道“这个元素要动”。
推荐写法（以侧边栏为例）：
.nav {
/* 基础状态：完全展开 */
transform: translateX(0);
transition: transform .25s cubic-bezier(0.22, 0.61, 0.36, 1);
will-change: transform; /* 提前提示 GPU 准备合成层 */
}
<p>.nav.collapsed {
transform: translateX(-100%);
}
</p>
注意事项：
-
will-change: transform不要滥用，仅对高频动画元素设置，否则可能增加内存开销 - 过渡时间控制在
.2s–.3s之间，过长显得拖沓，过短失去动效意义 - 避免同时设置
transform和width过渡，后者会降级为 CPU 渲染 - 确保父容器没有
overflow: hidden意外裁剪动画路径
Element Plus / Element UI 中的典型陷阱
Element 系列组件默认开启 collapse-transition，但它的实现依赖 v-show + opacity + height，而 height 是昂贵属性。一旦菜单项较多，每次折叠都会触发 layout 计算。
更稳妥的做法是绕过内置过渡，手动控制：
- 设置
:collapse-transition="false"关闭默认动画 - 用
transform: scaleX(0)或translateX(-100%)替代width: 0 - 配合
pointer-events: none防止折叠中途误点 - 若需保留图标区域，给
.el-menu--collapse单独设宽，避免 width 动态计算
容易被忽略的一点：折叠动画是否真正“结束”，取决于 JS 是否监听了 transitionend 事件。很多自定义收起逻辑在动画未完成时就修改了状态，导致下一次展开错乱。务必用事件校验，而不是靠 setTimeout 估算。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
