定时器递归模式下必须用 setTimeout 递归替代 setInterval；每次执行后 clearTimeout 清除旧定时器，再根据最新状态（如 speed[currentIndex]）调用 setTimeout 启动新定时器，并确保 useEffect 依赖项完整。
定时器递归模式下，执行间隔的动态调整不能靠“改参数”实现——因为 setInterval 创建后，其间隔值就已固化，后续修改变量不会影响正在运行的定时器。真正可行的方式是：每次执行完当前任务后，主动清除旧定时器，再根据最新状态（比如数组中当前项的值）启动一个新的 setTimeout。
用 setTimeout 递归替代 setInterval
这是最稳定、最易控制的方案。每次回调结束时，读取当前索引对应的延迟值，再调用一次 setTimeout，形成链式调用。
- 确保每次延迟都基于最新 state 或数组项（如
speed[currentIndex]），避免闭包捕获旧值 - 把当前索引和数组作为依赖项传入 useEffect（React 场景），或在函数内实时计算下一步索引
- 执行完毕后手动更新索引，并判断是否继续（例如
currentIndex ）
清理逻辑必须显式写入
递归定时器没有自动销毁机制，一旦状态变更（如用户暂停、数据重置、组件卸载），必须主动清除 pending 的 timeout。
- 用
useRef存储当前 timeout ID，便于在 effect 清理函数中调用clearTimeout - 如果数组长度为 0 或索引越界，应提前终止递归，防止无限 pending
- 切换数据源时（比如换了一组 speed 值），需先清空旧 timer，再用新数组重启流程
数组驱动的延迟切换示例
假设你有一组节奏值 [1000, 3000, 500, 2000]，希望每一步按对应毫秒执行：
- 第 1 步延迟 1000ms → 执行 → 更新索引为 1
- 第 2 步读取
speed[1] === 3000→ 延迟 3000ms → 执行 → 更新索引为 2 - 以此类推，每步都重新计算，不复用任何固定周期
避免常见陷阱
不要试图在 setInterval 回调里修改 delay 变量并期望它生效——浏览器不会刷新已启动的定时器间隔。
- 错误做法：
let delay = 1000; setInterval(() => { delay *= 1.2; }, delay)—— 实际只按初始 1000ms 运行 - 正确做法：每次执行后
clearTimeout(prevId)，再setTimeout(nextFn, newDelay) - 在 React 中尤其要注意 useEffect 的依赖数组完整性，漏掉
speed或currentIndex会导致 stale state 问题
