Tailwind的transition类需配合状态变化才生效，单独使用无效；必须定义起始与结束样式（如hover:text-blue-500），并确保过渡属性匹配（如transform需transition-transform），避免滥用transition-all或误用不可过渡属性。
transition类为什么加了却没动画
单独写 transition 或 transition-all 在元素上，悬停时毫无反应——这是最常被卡住的第一步。根本原因：Tailwind 的 transition 类只是设置 transition-property、transition-duration 等 CSS 属性，它不负责“触发变化”。没有起始态和结束态的样式差异，就不存在可过渡的过程。
常见错误包括：
- 只写
div transition-all，但没配hover:bg-blue-500或 JS 切换的 class - 用
hover:underline期望下划线淡入——但text-decoration不支持过渡，浏览器直接忽略 - 对
display: none/height: auto做 transition，这两者根本不可动画
正确做法是始终成对出现：一个基础态 + 一个状态变更类（hover:、group-hover:、或 JS 控制的 class 切换）。
哪些属性真正能平滑过渡
不是所有 CSS 属性都适合做 transition。Tailwind 默认的 transition（等价于 transition-colors duration-150）只覆盖颜色、背景、边框、文本装饰等安全属性。想动得顺，得选对目标：
立即学习“前端免费学习笔记（深入）”；
-
transform和opacity是 GPU 加速的，无重排，首选：用transition-transform+hover:scale-110，或transition-opacity+opacity-0 -
width/height易触发重排，Tailwind v3.0+ 默认禁用transition-width；改用transform: scaleX()模拟进度条更稳 -
max-height可动画，适合菜单展开/收起；但必须设足够大的目标值（如max-h-96），不能用max-h-full - 避免
transition-all：它会连box-shadow、filter一起过渡，可能卡顿或意外抖动
JS 控制动画时怎么不卡顿
用 JS 动态更新进度、展开状态或滚动位置时，性能崩塌往往来自隐式重排。关键不是“能不能动”，而是“怎么动才不打断渲染流水线”：
- 别反复读取
offsetWidth、clientHeight—— 这会强制同步布局计算 - 别用 classList 切换一堆
w-1/4、w-1/2类来模拟 width 变化；改用el.style.transform = 'scaleX(0.7)' - 批量更新优先走
requestAnimationFrame：比如raf(() => el.style.transform = `scaleX(${progress})`) - 对长时动画（如持续 >500ms 的缩放），加
will-change: transform提前提示浏览器优化，但别滥用 - 响应式容器里，记得给进度条父容器加
min-w-0，否则 flex/gap 可能撑开宽度，让scaleX失效
自定义动画要不要装插件
内置 animate-spin、animate-pulse 足够简单场景，但一旦需要入场/退场控制、方向滑动、或 stagger 效果，就得靠插件。目前两个主流选择：
-
tailwindcss-animate：轻量，开箱即用animate-in/animate-out，支持slide-in-from-left、fade-in，duration/delay 可用工具类微调 -
tailwindcss-motion：企业级，提供预设组合（如motion-preset-slide-up）、CSS 变量控制（--motion-translate-in-animation），适合统一动效规范
插件不是银弹。复杂交互动画（比如手风琴折叠+滚动定位+焦点管理）仍需结合 JS 状态与 CSS 变量协同，单纯堆工具类容易失控。
真正难的从来不是“怎么让元素动起来”，而是动的时候不抢主线程、不破坏布局流、不和响应式规则打架——这些细节藏在 origin-left、min-w-0、overflow-hidden 这些不起眼的 class 里。
