怎么用Promise和async/await实现JS睡眠函数

一、核心答案：两行代码实现睡眠函数

最精简、最通用的 JavaScript 睡眠函数实现方式，是将定时器 setTimeout 包装在一个 Promise 对象中，并在需要等待的地方使用 await 关键字挂起当前函数的执行：

// 1. 定义非阻塞睡眠函数
const sleep = (ms) => new Promise((resolve) => setTimeout(resolve, ms));

// 2. 在 async 函数中使用 await 进行等待
async function main() {
  console.log("开始执行...");
  
  await sleep(2000); // 代码在此处暂停等待 2000 毫秒（2 秒）
  
  console.log("2秒后继续执行这一行");
}

main();

这段代码的执行效果非常纯粹：控制台会立即打印出 "开始执行..."，经过两秒钟后，打印出 "2秒后继续执行这一行"。整个过程无需嵌套任何回调函数，阅读体验就像传统的同步代码一样直观自然。

要透彻理解这段代码为什么生效，可以将其拆解为三个紧密相连的技术要点：

1. 计时契约：new Promise(resolve => ...) 在被实例化时处于等待态（Pending）。我们将 resolve 函数本身作为 setTimeout 的回调传入，意味着只有当计时器到期后，resolve() 才会执行，Promise 才会转为已完成（Fulfilled）。
2. 协程让出：await sleep(ms) 表达式会暂时挂起（Suspend）外层 async 函数的上下文，将主线程控制权交还给 JavaScript 引擎，而不是傻傻占着 CPU。
3. 恢复执行：当 ms 毫秒过去，定时器将 Promise 状态决议为完成，事件循环就会在下一个微任务时机唤醒被挂起的函数，从 await 处的下一行接着向下运行。

二、核心机制解析：为什么它不会卡死页面？

初学者常常会问：“既然 JavaScript 是单线程的，为什么 await sleep(2000) 等待了两秒，而页面上的按钮依然可以点击、动画依然流畅不卡呢？”

为了讲清这个关键问题，我们需要在相同条件下，对比两种截然不同的“实现睡眠”的方式：同步死循环阻塞与异步非阻塞协程挂起。

1. 为什么坚决不能用同步 while 死循环？

很多初学者可能会写出类似 while (Date.now() < end) 的死循环代码试图让线程等待。这种做法在 JavaScript 单线程模型下是极具破坏性的灾难操作：

• 主线程持续被霸占：CPU 核心利用率立刻飙升至 100%，主线程的调用栈（Call Stack）永远处于繁忙状态。
• 事件循环被死锁：浏览器的 GUI 渲染线程、用户的鼠标点击、键盘输入、网络响应都被堵在任务队列外无法处理。在浏览器中，这会导致页面瞬间冻结；在 Node.js 中，会导致整个服务在休眠期间无法响应任何并发请求。

2. Promise + async/await 是如何做到“非阻塞”的？

相反，基于 Promise 与 setTimeout 的睡眠函数遵循了浏览器的宿主调度规范。当执行到 await sleep(ms) 时：

• setTimeout 的计时工作是由浏览器底层操作系统或多线程计时器独立完成的，根本不需要 JavaScript 主线程消耗算力去持续检查时间。
• 调用栈直接被清空，主线程在等待的两秒钟里可以毫无阻碍地处理用户交互、绘制 CSS 动画、执行其他函数的代码。

三、规范化封装与高频实战场景

1. 标准函数声明与 TypeScript 强类型支持

在正式的工程项目中，推荐将睡眠函数封装为独立模块，并添加参数防御性检查与 TypeScript 类型定义：

/**
 * 非阻塞延迟等待指定毫秒数
 * @param ms 等待的毫秒数（必须为非负数值）
 * @returns 当指定时间耗尽后 Resolve 的 Promise
 */
export function sleep(ms: number): Promise<void> {
  const duration = Math.max(0, ms); // 避免负数导致不确定行为
  return new Promise((resolve) => setTimeout(resolve, duration));
}

2. 典型实战场景 1：网络请求重试与指数退避（Exponential Backoff）

调用外部 API 遇到网络波动或临时限频（429 Too Many Requests）时，无间隔连续重试只会加剧服务端负担。利用 sleep 配合指数退避机制是最标准的企业级实践：

async function fetchWithRetry(url, maxRetries = 3, baseDelay = 1000) {
  for (let attempt = 1; attempt <= maxRetries; attempt++) {
    try {
      const response = await fetch(url);
      if (!response.ok) throw new Error(`HTTP error! status: ${response.status}`);
      return await response.json();
    } catch (error) {
      if (attempt === maxRetries) throw error;
      
      // 指数递增等待：第1次等1秒，第2次等2秒，第3次等4秒
      const delayTime = baseDelay * Math.pow(2, attempt - 1);
      console.warn(`第 ${attempt} 次请求失败，将在 ${delayTime}ms 后重试...`);
      await sleep(delayTime);
    }
  }
}

3. 进阶能力：支持中断取消的睡眠函数（AbortSignal）

在现代前端框架（如 React / Vue）中，如果用户在一个睡眠操作尚未完成时跳转了路由，或者组件被卸载，未完成的 setTimeout 会滞留在内存中。如果它在随后被触发并尝试更新已卸载组件的视图，就会引发控制台报错或内存泄漏。

使用 Web 标准的 AbortController 和 AbortSignal，我们可以实现随时可被主动取消的生产级睡眠函数：

function cancellableSleep(ms, signal) {
  return new Promise((resolve, reject) => {
    // 如果传入的 signal 已经被取消，立即抛出 AbortError
    if (signal?.aborted) {
      return reject(new DOMException("Sleep was aborted", "AbortError"));
    }

    let timer;
    const abortHandler = () => {
      clearTimeout(timer); // 清除底层定时器
      reject(new DOMException("Sleep was aborted", "AbortError"));
    };

    timer = setTimeout(() => {
      signal?.removeEventListener("abort", abortHandler);
      resolve();
    }, ms);

    signal?.addEventListener("abort", abortHandler, { once: true });
  });
}

四、常见误区与避坑指南

const items = [1, 2, 3];

// ✕ 错误写法：forEach 内部的 await 不会导致循环依次等待！
items.forEach(async (item) => {
  await sleep(1000);
  console.log(item); // 结果：1秒后 1, 2, 3 几乎同时被打印，并非间隔打印！
});

// ✓ 正确写法：使用原生的 for...of 循环，保证严格串行等待
async function processSequentially() {
  for (const item of items) {
    await sleep(1000);
    console.log(item); // 每隔 1 秒依次输出一个数值
  }
}