0.1s过渡看起来像没动，因人眼难捕捉且60fps下仅约6帧，易感知为跳变；建议基础交互至少0.2s，禁用≤0.05s或≥0.5s以避免失效或卡顿。
transition-duration 设为 0.1s 为什么看起来像没动？
0.1 秒（即 0.1s）在视觉上接近瞬时变化，人眼难以捕捉过渡过程，尤其在颜色、透明度这类无位移的属性上。浏览器渲染帧率通常为 60fps（约每帧 16.7ms），0.1s 仅含约 6 帧，动画极易被感知为“跳变”。这不是 bug，是生理限制。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 基础交互反馈（如按钮 hover）建议从
0.2s起步，兼顾响应感与可感知性 - 若必须极快（如菜单展开后快速收起），可用
0.08s，但需搭配transition-timing-function: ease-out强化初段速度感 - 避免使用
0s或0.05s—— 这类值实际等效于无过渡，且可能触发浏览器跳过合成层优化
transition-duration 超过 0.5s 后用户明显感到卡顿
超过 0.5s 的过渡容易让界面显得迟缓，尤其在频繁触发的场景（如导航栏悬停、标签页切换）。用户会下意识等待动画结束才敢点击，造成操作阻塞。更关键的是，长时长放大了 timing function 的偏差影响 —— 比如 ease-in 在前半程几乎不动，后半程突然加速，体验割裂。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 非模态动效（如背景渐变、卡片浮起）上限建议控制在
0.4s内 - 模态层入场（如弹窗、抽屉）可放宽至
0.5s，但必须用cubic-bezier(0.34, 1.56, 0.64, 1)类“缓入缓出”曲线平衡节奏 - 禁用
transition-duration: 1s等整秒值 —— 容易与页面加载、网络延迟混淆，用户分不清是动画慢还是系统卡
不同属性对 transition-duration 的敏感度差异很大
不是所有 css 属性过渡都需要相同时长。例如 transform 和 opacity 渲染效率高、人眼敏感度低，可稍快；而 height、width 触发重排且变化直观，需更谨慎。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 优先给高效属性单独设时长：
transition: opacity 0.2s, transform 0.25s - 避免通配符写法：
transition: all 0.3s—— 一旦后续加了box-shadow或Filter，过渡会意外变重 -
height过渡慎用固定时长：内容高度差异大时，0.3s对 20px 高度是拖沓，对 200px 又显仓促；改用max-height+0.4s更稳妥
响应式场景下 transition-duration 需要动态调整
小屏触控设备手指操作精度低，用户需要更明确的反馈节奏；而桌面端鼠标悬停响应更快，过渡可以更紧凑。硬编码统一值会导致移动端“太冲”、桌面端“太拖”。CSS 媒体查询本身不支持根据设备输入类型动态改 transition-duration，得靠其他方式。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用
@media (hover: hover)区分悬停能力，桌面设0.25s，触屏设0.35s - javaScript 检测
'ontouchstart' in window后，给加 class，再用 CSS 覆盖：.touch-supported .btn { transition-duration: 0.3s; } - 禁用 js 动态内联 style 设置
transitionDuration—— 容易和 CSS 中的声明冲突，且无法利用 CSS 缓存
过渡时间不是越短越灵敏，也不是越长越优雅。真正难的是在 0.2s 到 0.4s 这个窄带里，针对不同属性、不同设备、不同交互意图做微调 —— 多数人栽在忽略这三者的耦合关系上。