settimeout本身不保障执行顺序，仅按注册时间与延迟将回调推入宏任务队列；链式调用靠在前一个回调中动态注册下一个settimeout实现串行效果；上下文传递需手动处理，推荐用promise链、async/await或自定义调度器替代。
setTimeout 本身不保障执行顺序，它只按注册时间与延迟参数将回调推入宏任务队列；真正决定“顺序感”的，是开发者对注册时机的控制——即在前一个回调里动态调用下一个 setTimeout。
链式 setTimeout 的执行逻辑靠“嵌套注册”实现
所谓“链式”，不是 setTimeout 自带顺序机制，而是人为把下一层定时器写在上一层回调内部。这样，只有当前层执行完，下一层才会被注册，从而形成时序依赖：
- 第一层 setTimeout 注册后立即返回，不阻塞后续代码
- 它的回调执行时，才调用第二层 setTimeout —— 此时第二层才真正进入任务队列
- 同理，第三层只在第二层回调中注册，依此类推
这种写法模拟了串行效果，但本质仍是多个独立宏任务，只是注册时机被严格串行化。
上下文传递需手动处理，不能依赖闭包自动保留
链式调用中，若需把初始参数、状态或中间结果传给后续步骤，不能指望 setTimeout 自动携带，必须显式传递：
- 用闭包捕获变量：外层函数定义的变量，在内层回调中仍可访问（只要未被垃圾回收）
- 把数据作为参数传入回调：例如
setTimeout(() => step2(data), 1000) - 避免在循环中直接使用循环变量：i++ 后再执行的回调可能读到错误值，应使用立即执行函数或 let 声明
替代方案更清晰地表达上下文流转
当链路变长或逻辑复杂时，链式 setTimeout 容易嵌套过深、难以调试。推荐用以下方式替代：
- Promise 链：每个
setTimeout封装成 Promise，用.then()串联，天然支持参数传递和错误捕获 - async/await：配合封装好的 delay 函数，让异步等待写起来像同步代码，上下文自然延续
- 自定义调度器：用队列 + 状态机管理步骤，适合需要暂停、重试、取消的场景
这些方式不改变事件循环本质，但让上下文传递更可控、更易维护。
