transition-duration 仅控制动画时长，不优化响应；卡顿主因是重排、未启用硬件加速或主线程阻塞，应优先用 transform/opacity，避免触发布局的属性，并配合 will-change 和渲染面板验证加速效果。
transition-duration 本身不优化交互响应，它只是控制动画时长；真正影响“用户感觉快不快”的，是是否触发重排（reflow）、是否启用硬件加速、以及是否在主线程上做耗时计算。
为什么设成 0.1s 有时反而更卡
短时长（如 0.1s）会让浏览器把动画帧压得更紧，但若样式变更触发了 layout（比如改 width、height、top），浏览器必须同步计算布局 → 强制同步重排 → 主线程卡住。用户反而觉得“顿一下才动”。
- 避免对
width、height、left、top等触发布局的属性做transition - 优先用
transform和opacity：它们走合成层（compositor thread），不触发重排重绘 - 如果必须用
height: 0 → height: auto，改用max-height过渡（设一个足够大的固定值，如max-height: 500px）
transition-duration 和 will-change 配合失效的常见原因
写了 will-change: transform + transition: transform 0.2s 却没加速？大概率是：
-
will-change被提前移除（比如 JS 动态加 class 后又立刻 remove，导致浏览器来不及提升图层） - 父容器有
overflow: hidden或transform: scale(1)等，抑制了图层提升 - 过渡起始/结束状态中混用了
transform: translateX(10px)和left: 10px，造成属性冲突，浏览器降级回软件渲染
验证是否真走了硬件加速：打开 Chrome DevTools → Rendering 面板 → 勾选 “Paint flashing” 和 “Layer borders”。动起来时看到绿色闪动+图层边框，才算生效。
立即学习“前端免费学习笔记（深入）”；
移动端触摸反馈延迟怎么破
点击按钮后 :active 样式延迟 300ms？这不是 transition-duration 的问题，是移动端双击缩放检测导致的默认延迟。
- 根本解法是加
touch-action: manipulation到按钮或全局 body —— 它告诉浏览器“这个区域只做点击/拖拽，别等双击” - 若需保留缩放，改用
viewportmeta 的user-scalable=yes+ JS 拦截touchstart并preventDefault()（慎用，影响可访问性） -
transition-duration可设为0.06s（≈ 1 帧），配合transform: scale(0.98)，比background-color变化更跟手
真正卡顿往往藏在 transition 起始点：比如 hover 触发时才计算某个复杂 filter，或 JS 正在跑 heavy task 占着主线程。别只盯着 duration 数值，先看 performance 面板里那几帧到底在干什么。
