javascript异步编程本质是避免阻塞主线程，核心靠事件循环与任务队列调度；回调易致嵌套地狱和错误失控，promise解决结构性缺陷但需防链断裂，async/await为推荐语法糖，旧api需封装为promise以统一处理。
JavaScript 异步编程本质是避免阻塞主线程
它不是“让代码跑得更快”，而是让 UI 保持响应、网络请求不卡住页面、大量计算不冻结浏览器。核心机制是事件循环（Event Loop）配合任务队列（microtask / macrotask），所有异步操作最终都靠它调度执行。
回调函数容易陷入“地狱嵌套”和错误处理失控
回调本身没毛病，但实际写多了就会暴露问题：多层嵌套难读、错误必须手动层层传、无法用 try/catch 捕获、控制流难以中断或并发管理。
-
fs.readFile套fs.writeFile再套setTimeout，缩进越来越深，逻辑支离破碎 - 每个回调里都要写
if (err) return handleError(err)，漏一次就静默失败 - 想同时发 3 个请求并等全部完成？得自己计数、判断状态，容易出竞态
fs.readFile('a.txt', (err, a) => {
if (err) return cb(err);
fs.readFile('b.txt', (err, b) => {
if (err) return cb(err);
fs.readFile('c.txt', (err, c) => {
if (err) return cb(err);
cb(null, [a, b, c]);
});
});
});
Promise 不是银弹，但解决了回调的结构性缺陷
Promise 把“异步结果”变成可传递、可组合的一等值，错误能冒泡、链式调用清晰、原生支持并发（Promise.all）、可被 async/await 消费。但它不解决回调函数本身的问题——比如忘记 .catch() 或误用 then 返回非 Promise 值导致链断裂。
-
fetch(url).then(res => res.json()).catch(handleError)错误自动上抛，不用每层检查 -
Promise.all([p1, p2, p3])简洁表达“全成功才继续”，失败则立刻 reject - 返回值自动包装：即使
then回调里写return 'hello'，下个then也能接收到字符串
fetch('/api/a')
.then(res => res.json())
.then(data => fetch(`/api/b?id=${data.id}`))
.then(res => res.json())
.catch(err => console.error('请求链任一环节失败:', err));
别纠结“哪个更优”，要清楚“在什么场景下必须用哪个”
现代代码应优先用 async/await（本质是 Promise 语法糖），但你仍会频繁遇到回调：Node.js 的 fs.readFile、setTimeout、事件监听器（element.addEventListener）、第三方库的旧 API（如 google.maps.places.Autocomplete）。这时候不是选“优劣”，而是怎么安全桥接：用 Promise 包一层回调，或者用 util.promisify（Node.js）自动转换。
立即学习“Java免费学习笔记（深入）”；
- Node.js 14+ 的
fs.promises.readFile是推荐替代，比手写new Promise(...)更可靠 - 对老式回调 API，别直接嵌套，先封装：
const promisified = () => new Promise(...) -
async函数里混用await和回调？危险。一旦回调里抛错，try/catch捕不到，必须确保所有异步路径都走 Promise 链
真正容易被忽略的点：Promise 构造函数里的执行器（executor）是同步运行的，而内部的 resolve/reject 才是异步触发点——这个时序差异，常导致你以为“还没执行”，其实已经进了 microtask 队列。
