应设为具体属性名而非all，如transform、opacity；timing-function优先用cubic-bezier调试；delay失效多因强制布局，需用requestanimationframe规避；transitionend监听需避免display切换和伪元素限制。
transition-property 该设成 all 还是具体属性名
设成 all 看似省事，实际容易引发意料外的重绘和卡顿。浏览器会对所有可动画属性（包括 box-shadow、transform、opacity 甚至 z-index）尝试做过渡，而其中很多根本不需要动。
更稳妥的做法是明确列出真正要过渡的属性：
-
transition-property: transform, opacity—— 最常用组合，GPU 加速友好 - 避免写
transition-property: all，尤其在复杂列表或滚动区域里 - 如果多个状态需不同过渡行为（比如 hover 用
transform，focus 用color），就别共用一个 transition 声明，改用单独类控制
transition-timing-function 选 ease-in-out 还是 cubic-bezier(0.34, 1.56, 0.64, 1)
默认的 ease 和 ease-in-out 在按钮反馈、卡片展开等简单场景够用；但一旦涉及手势驱动、视差滚动或跟随式交互动画，它们的加速度曲线就太“钝”了。
真正可控的方式是手写 cubic-bezier()：
立即学习“前端免费学习笔记（深入）”；
-
cubic-bezier(0.34, 1.56, 0.64, 1)是个常见“缓出强回弹”曲线，适合模拟物理惯性，但注意第二参数 > 1 会超出 y 轴范围，导致视觉上“超调” - 第一、三参数决定起始/结束斜率，第二、四参数决定控制点高度；值越夸张，运动越“有弹性”，但也越难预测
- 不要盲目复制网上“高级动效曲线”，先在 Chrome DevTools 的 animation 面板里拖动调试，看它在真实 DOM 上的节奏是否自然
transition-delay 触发后没反应？检查是否被 layout 触发阻塞
写了 transition-delay: 0.2s 却没看到延迟效果，大概率不是 CSS 写错了，而是 JS 或样式变更触发了同步 layout 计算，把 delay “吃掉”了。
典型诱因有：
- 在添加 class 后立刻读取
offsetHeight、getComputedStyle(el).height等触发强制同步布局 - 同一帧内既改 class 又改内联 style，浏览器可能合并渲染，跳过中间态
- 父容器用了
will-change: transform但子元素又频繁改top/left，导致合成层混乱，delay 失效
解法很简单：用 setTimeout(() => {}, 0) 或 requestAnimationFrame 把读取操作推到下一帧。
transitionend 事件监听不到？注意伪元素和 display 切换
transitionend 不会触发，十有八九是因为目标元素在动画过程中被移除、隐藏或脱离文档流。
特别要注意两种情况：
- 用
display: none切换显隐时，transition 完全不执行 —— 改用visibility: hidden+opacity: 0组合 - 对伪元素（
::before/::after）设置 transition，但 JS 无法直接监听其transitionend，得监听宿主元素并靠 class 变化间接判断 - 多个属性同时过渡（如
transform和opacity），会触发多次transitionend，记得用event.propertyName过滤，别一上来就执行清理逻辑
过渡真正难的不是写几行 CSS，而是判断哪一帧该动、哪一帧该停、哪一帧根本不能动。浏览器渲染管线不等人，你写的每条 transition 都得经得起重排重绘的拷问。
