transition-delay 本身不导致迟钝，但暴露主线程阻塞、样式未及时应用或过渡未启动等底层渲染问题；常见失效原因包括属性声明错误、简写覆盖、JS同步操作及长任务阻塞。
transition-delay 本身不会让交互变迟钝，但它的存在暴露了更底层的渲染问题——延迟没生效时，你看到的“迟钝”其实是主线程被卡住、样式未及时应用、或过渡根本没启动。
transition-delay 失效时，浏览器其实在跳过它
写了 transition-delay: 0.2s 却感觉“卡了一下才动”，大概率不是 delay 在起作用，而是：
- transition-property 没声明目标属性（比如只改了 opacity，但 transition-property 写的是 transform）
- 用了 transition: all 0.3s，再单独加 transition-delay → 后者被简写覆盖，压根不生效
- JS 同步修改 class 和 style（如 el.classList.add('active'); el.style.opacity = '1';），浏览器合并成一次重排，直接跳过 delay 阶段
- 主线程正执行长任务（比如解析大 JSON、跑复杂计算），第一帧渲染被推迟，delay 看起来像“卡住”
hover 场景下 delay 表现正常，JS 场景下却容易翻车
伪类切换（:hover）由浏览器原生控制时机，能精准捕获状态进入点；而 JS 触发依赖开发者对渲染队列的理解。常见陷阱包括：
- 动态加 class 后立刻读取 offsetHeight 或 getBoundingClientRect() → 强制同步布局，打断 delay 流程
- 在 click 回调里连续触发多个状态变更（比如快速开关菜单），浏览器可能合并帧，导致 delay 被忽略或累积
- 用 setTimeout(() => el.classList.add('fade'), 0) 并不能保证 delay 生效，因为仍是微任务队列，未必触发新渲染帧
负值 delay 不是“加速”，是跳帧，反而放大卡顿感
transition-delay: -0.3s 的真实含义是：状态一变，属性值立刻跳到“已执行 0.3 秒后”的中间态，再走完剩下时间。但它依赖两个前提：
- transition-duration 必须明确且大于 0.3s（否则动画直接完成）
- 过渡属性必须真能硬件加速（比如 transform），否则跳帧后仍得在主线程补算布局
如果页面本就因 left 或 width 触发重排，加负 delay 只会让第一帧更重，用户感觉是“闪一下再动”，而非跟手
真正拖慢交互的，往往藏在 transition 起始点
别只盯着 transition-delay 数值，先确认这些环节是否干净：
- :hover 或 JS class 切换时，有没有同步触发耗时 JS（比如遍历 DOM、计算 layout）
- 动画元素父容器是否带 overflow: hidden、filter: blur(1px) 或 backdrop-filter → 这些会压制图层提升，让 transform 也退化为 CPU 渲染
- 移动端是否还挂着 300ms 点击延迟（touch-action: manipulation 没加）→ transition-delay 根本等不到起点
- Chrome DevTools → Rendering → 勾选 “Layer borders”，动起来时没蓝边？说明 GPU 加速根本没起来，delay 再准也没用
