transition-delay设为0仍有延迟，主因是父元素继承、浏览器默认样式、all过渡滥用、触发时机不当、单位缺失或JS强制重排导致动画被推迟到下一帧。
transition-delay 设为 0 但还是有延迟？检查是否被继承或重置
很多情况下你写了 transition-delay: 0s，但动画依然“卡一下”才开始，根本原因常是父元素或浏览器默认样式悄悄带入了延迟。比如某些 UI 框架（如 Ant Design、Element Plus）的组件内部设置了 transition-delay: 0.15s，子元素没显式覆盖就会继承；或者你用了 all 做过渡，结果连 outline、box-shadow 这些不常动的属性也参与了延迟过渡。
- 用浏览器 DevTools 的「Computed」面板，直接查目标元素的最终
transition-delay值，别只看 Styles 面板里你写的那条 - 避免用
transition: all 0.3s ease;，改用明确属性列表：transition: background-color 0.3s ease, opacity 0.3s ease; - 如果父元素有
transition-delay，子元素必须显式设为transition-delay: 0s（不能只写0，有些旧浏览器不识别无单位的0）
transition 触发时机不对：hover 后要等几百毫秒才动？
这不是 transition-delay 的问题，而是触发条件本身有延迟。典型场景是：你对一个刚插入 DOM 的元素立即加 class 触发动画，但此时浏览器还没完成布局（layout），导致 transition 被跳过或延后一帧执行。
- 确保元素已挂载且尺寸/位置稳定后再触发动画 —— 比如在
requestAnimationFrame里加 class：
element.classList.add('is-active');
requestAnimationFrame(() => {
element.classList.add('animate-in');
});
- 对动态插入的元素，不要在
appendChild()后立刻设 class，先强制触发一次 layout（例如读取offsetHeight），再设 class - 检查是否用了
will-change: transform却没配对应属性 —— 这可能导致合成层创建延迟，间接拖慢 transition 起始
transition-duration 和 transition-delay 数值写错单位？
transition-delay 和 transition-duration 必须带单位（s 或 ms），漏掉会整个 transition 失效（浏览器忽略该声明）。尤其容易在 CSS 预处理器中因变量拼接出错，比如 $delay: 0; transition-delay: $delay + 's'; 写成 $delay + s 就变成 0s → 0s 是对的，但万一写成 $delay s，编译后就是 0 s（空格分隔），CSS 解析失败。
- 始终写全单位：
transition-delay: 0s，而不是0或0ms（0ms虽合法但易混淆，统一用s更安全） - 用 PostCSS 或 Stylelint 开启
time-no-imperceptible规则，自动拦截0.001s这类实际无效的值 - 在 DevTools 中鼠标悬停到 transition 声明上，如果显示「invalid value」，八成是单位或语法错了
JavaScript 强制重排（reflow）导致 transition 丢失首帧
当你用 JS 修改样式后立刻读取布局相关属性（如 offsetTop、getBoundingClientRect()），浏览器会同步计算布局，若此时 transition 尚未注册，就可能跳过第一帧，表现为“延迟启动”。这比单纯 delay 更隐蔽，因为控制台没报错，动画就是不动。
立即学习“前端免费学习笔记（深入）”；
- 修改样式和读取布局之间，加一层
requestAnimationFrame或setTimeout(..., 0)让浏览器有机会先注册 transition - 优先用
transform和opacity做动画 —— 它们触发合成层，基本不触发 reflow，自然避开这类问题 - 调试时临时加
transition: all 1s !important;到元素上，看是否突然“变慢但能动”，那就是触发时机问题，不是 delay 设置问题
