javascript异步编程怎样处理回调？【教程】_技术教程

回调本身不是需处理对象，而是异步完成时被调用的函数；真正问题是回调地狱、错误传递混乱和可读性差；Promise和async/await可解决控制流断裂与错误捕获难题。

JavaScript 异步编程中，回调（callback）本身不是“需要被处理”的对象，而是你主动传入、由异步操作在完成时调用的函数。真正要解决的，是回调带来的嵌套、错误传递混乱和可读性问题——也就是常说的“回调地狱”。

为什么直接写回调容易出错

手动管理回调最常踩的坑不是语法错误，而是控制流断裂：

setTimeout 或 fs.readFile 的回调里忘了 return，后续逻辑意外执行
错误没统一捕获：if (err) return callback(err) 漏写一次，整个链路就静默失败
多个并行异步操作时，靠手动计数判断完成（如 done++ === 3），极易因某次调用被跳过或重复触发而卡死
无法用 try/catch 捕获回调里的同步异常，更捕获不到异步抛出的错误

用 Promise 封装回调函数是最低成本升级

几乎所有 Node.js 核心模块（fs、dns）和浏览器 API（fetch、setTimeout）都支持 Promise 化。别自己手写 new Promise((resolve, reject) => {...}) 封装，优先用现成方案：

Node.js 14+ 直接用 util.promisify：

const { promisify } = require('util');
const readFile = promisify(fs.readFile);
readFile('./config.json', 'utf8')
  .then(data => JSON.parse(data))
  .catch(err => console.error('解析失败:', err));

浏览器中封装 setTimeout：

const delay = ms => new Promise(resolve => setTimeout(resolve, ms));
delay(1000).then(() => console.log('1秒后执行'));

不要为每个回调都写 Promise，只封装你真正要组合使用的部分

async/await 不是语法糖，它改变了错误传播路径

async/await 让你用同步写法表达异步逻

辑，但关键在于：它让 try/catch 第一次真正能捕获异步错误。

下面这段代码中，JSON.parse 抛异常会被 catch 捕获：

async function loadConfig() {
  try {
    const data = await fs.promises.readFile('./config.json');
    return JSON.parse(data);
  } catch (err) {
    // 这里能同时捕获文件读取失败和 JSON 解析失败
    throw new Error(`配置加载失败: ${err.message}`);
  }
}

但注意：await 只解包一层 Promise，如果 JSON.parse 返回的是另一个 Promise，你得再 await 一次
await 后面如果不是 Promise，会自动包装成 Promise.resolve(value)，所以 await 42 是合法的

回调还没消失，只是藏得更深了

你仍然会在某些场景下碰到回调：事件监听（addEventListener）、Stream 处理（stream.on('data', ...)）、第三方库（如 redis.client.get(key, callback)）。这时别硬套 async，而是明确它的角色：

它不是“主流程”，而是“响应式钩子”——不参与返回值链，只做副作用（打日志、更新 UI、发请求）
如果必须把回调转成 Promise（比如等某个事件触发一次），用 once（Node.js）或手动 new Promise + removeEventListener，但仅限必要时
永远检查文档：Redis 有 getAsync，MongoDB 驱动默认返回 Promise，别一上来就写回调

真正的难点不在语法转换，而在判断哪部分逻辑该串行、哪部分该并发、错误该在哪个层级聚合。回调只是暴露了这些问题，而不是造成它们的原因。