结论：优化 transition 的核心是精准控制触发时机、过渡属性和执行次数，而非简单删除；需明确指定 transition-property、禁用非交互区动画、防抖状态切换、优先使用合成属性（transform/opacity）、合理使用 will-change 并及时清除，最终回归动效本质——仅在必要处引导用户注意力。
直接说结论：减少动态效果设置，不是删 transition，而是控制它“什么时候动、动什么、动几次”。关键在避免无意义触发和属性滥用。
transition 触发条件不明确导致意外动画
常见现象是鼠标快速进出、滚动中 class 切换、JS 频繁改样式时，元素反复闪动或卡顿。根本原因是 transition 对所有符合条件的属性变化都响应，没做边界约束。
- 用
transition-property明确指定要过渡的属性，比如只写transition: opacity 0.2s, transform 0.2s，别用all - 对非交互区域（如静态文案容器）移除所有
transition声明，哪怕只是 0.1s - 用
pointer-events: none在动画进行中临时禁用事件，防止连续 hover 触发堆积 - JS 控制状态切换时，加简单防抖：比如
setTimeout延迟 class 切换，或用requestAnimationFrame对齐帧率
对非合成属性用 transition 导致强制重排
浏览器看到 transition: width 0.3s 或 left 0.3s，会每帧计算布局，CPU 拉满，尤其在低端设备上明显掉帧。
- 移动元素优先用
transform: translateX()替代left/top - 缩放/显示隐藏优先用
transform: scale()和opacity，而不是width/height/visibility - 背景色渐变不用
background-color过渡，改用半透明遮罩层 +opacity控制显隐 - 检查 DevTools 的 “Layers” 面板，确认动画元素是否生成了独立合成层；没生成，说明还在主线程跑 Layout/Paint
will-change 使用不当反而拖慢性能
will-change: transform 不是开关，它是给渲染引擎的“预告”，提前分配资源。但长期开着，等于让 GPU 一直盯一个不动的元素，内存占用上升，其他动画反而卡。
立即学习“前端免费学习笔记（深入）”；
- 只在动画开始前 JS 动态加：
el.style.willChange = 'transform' - 动画结束后立刻移除：
el.style.willChange = 'auto'或空字符串 - 绝对不要写
will-change: all，也别对body或滚动容器设这个 - 现代浏览器（Chrome 110+、Safari 16.4+）对
transform自动启用合成层，translateZ(0)已基本失效，老项目兼容可留，新项目不必加
真正难处理的不是怎么写 transition，而是判断“这里到底需不需要动”。很多所谓“优化”，其实是先砍掉 70% 的过渡需求——比如导航菜单展开用 transition，但页脚版权文字颜色变化完全没必要。动效的价值在于引导注意力，不是填满每一处变化。
