transition-delay无效的主因是目标属性未在transition-property中声明或使用all；JS同步修改样式会跳过延迟，需强制重排；负值被忽略，display:none会中断延迟。
transition-delay 设置后没效果的常见原因
直接原因是 transition-delay 只对「触发过渡的属性变化」起作用，而很多人误以为它能延迟整个动画启动或影响未声明 transition-property 的属性。如果目标属性没在 transition 中显式列出（或用 all），延迟就完全不生效。
- 检查是否漏写了
transition-property或用了none—— 比如transition: opacity 0.3s;不含delay，transition-delay单独设无效 - 确认触发方式：必须是 CSS 属性值发生「可过渡变化」，比如
opacity从 0→1、transform从scale(1)→scale(1.2)；写死的初始值或 JS 强制重排（如读取offsetHeight后立刻改样式）可能跳过延迟阶段 -
transition-delay是相对「状态切换时刻」计算的，不是相对页面加载或鼠标按下——如果状态切得太快（比如 hover 离开又马上回来），浏览器可能合并帧，看起来像延迟失效
transition-delay 与 transition-timing-function 的配合误区
transition-delay 控制的是「等待多久才开始过渡」，而 transition-timing-function 控制的是「开始之后怎么动」。两者不冲突，但容易混淆表现。比如设了 transition-delay: 1s 和 transition-timing-function: ease-in，实际是：等 1 秒 → 然后用 ease-in 动画跑完剩余时间。
- 不要指望
ease-in或cubic-bezier(0,0,0.58,1)能“模拟延迟”——它只是开头慢，不是真停住 - 若需「先停、再动、再停」，必须用
@keyframes+animation-delay，transition无法实现多段时序 - 多个属性过渡时，
transition-delay可以是单值（统一延迟）或列表值（如transition-delay: 0.2s, 0.5s;），但必须和transition-property顺序严格对应
JS 触发 transition-delay 失效的典型场景
用 JavaScript 添加 class 或修改 style 时，如果「添加样式」和「触发重排」在同一个任务中完成，浏览器会跳过延迟，直接执行过渡。这是最隐蔽也最常踩的坑。
- 错误写法：
el.classList.add('active');
el.style.opacity = '1'; // 立即触发，delay 被忽略 - 正确写法：强制分隔渲染任务，比如用
setTimeout或getComputedStyle触发重排el.classList.add('active');
getComputedStyle(el).opacity; // 强制重排
el.style.opacity = '1'; - 更稳妥的方式是只用 class 控制样式，把所有过渡相关声明都写在 CSS 里，避免内联 style 干扰
浏览器兼容性与 transition-delay 的隐性限制
现代浏览器都支持 transition-delay，但要注意两点：一是它不支持负值（负值会被忽略，不是倒播）；二是当父元素 display: none 时，子元素所有 transition（包括 delay）都会被中断，即使父元素 later 改为 block，也不会补上延迟。
立即学习“前端免费学习笔记（深入）”；
- 移动端 Safari 对
transition-delay在某些复合变换（如同时改transform和opacity）下偶有渲染抖动，建议用will-change提前提示：will-change: opacity, transform; - 如果 delay 设为
0s或0ms，部分旧版 Android Webview 会当作未设置，降级为无延迟——统一用0.01s更可靠 - 使用
transition: all 0.3s ease 0.2s;看似方便，但会过渡所有可动画属性（包括意外的box-shadow、color），导致性能下降或视觉干扰
