JavaScript异步编程演进是为提升可读性与控制流：回调函数易致“回调地狱”，Promise用状态和链式调用统一错误处理与并发，async/await则以语法糖实现同步式书写体验，三者叠加演进而非替代。
JavaScript 异步编程的演进，本质是开发者不断对抗“可读性损耗”和“控制流失序”的过程。它不是功能堆砌，而是语言为人类思维让步的结果：从被迫适应异步，到让异步看起来像同步。
回调函数：简单但不可扩展的起点
回调是最原始的异步表达方式，比如 setTimeout、XMLHttpRequest.onload 或 Node.js 的 fs.readFile，都依赖传入一个函数，在操作完成后执行它。
单层回调清晰直接：
fs.readFile('config.json', 'utf8', (err, data) => {
if (err) throw err;
console.log(JSON.parse(data));
});
立即学习“Java免费学习笔记（深入）”；
但一旦需要串行多个依赖操作，缩进就层层加深，错误处理分散，逻辑支离破碎——这就是“回调地狱”。它不难写，但极难改、难测、难调试。
Promise：用状态和链式调用重建秩序
ES6 引入 Promise，核心是把异步操作包装成一个有明确状态（pending / fulfilled / rejected）的对象，并提供统一的 .then() 和 .catch() 接口。
- 每个
.then()返回一个新 Promise，天然支持链式调用，扁平化嵌套 - 错误可集中捕获：
.catch()会捕获链中任意环节抛出的异常或 reject - 支持并发控制：
Promise.all()等待全部完成，Promise.race()响应最快结果
它解决了结构问题，但代码仍需显式书写 .then()，语义上仍是“注册回调”，而非“等待结果”。
async/await：让异步代码回归线性直觉
ES2017 的 async/await 是基于 Promise 的语法糖，目标只有一个：写起来像同步，跑起来仍是异步。
-
await只能在async函数内使用，它暂停函数执行，直到 Promise settle，然后继续向下 - 错误可用熟悉的
try/catch捕获，与同步代码完全一致 - 顺序逻辑一目了然，调试体验接近同步代码（断点可逐行停）
例如三个串行请求：
async function loadUserProfile(userId) {
try {
const user = await fetch(`/api/users/${userId}`).then(r => r.json());
const profile = await fetch(`/api/profiles/${user.id}`).then(r => r.json());
const permissions = await fetch(`/api/perm/${profile.role}`).then(r => r.json());
return { user, profile, permissions };
} catch (err) {
console.error('加载失败:', err);
}
}
三者关系不是替代，而是叠加演进
async/await 并没有取代 Promise，它底层完全依赖 Promise；Promise 也没有废掉回调，很多底层 API（如事件监听、Node.js 流）仍以回调形式存在。
- 回调是基石：所有异步机制最终都要靠事件循环触发回调
- Promise 是抽象：把“成功/失败”封装成可组合、可传递的一等值
- async/await 是体验：在 Promise 基础上，提供最贴近自然语言的控制流语法
今天写业务逻辑，首选 async/await；封装底层工具时，常直接返回 Promise；而理解回调，是读懂事件循环和调试底层行为的关键。
