平滑迁移旧代码的关键是分四步渐进式改造：先封装回调为promise，再用async/await替换调用链，接着重构控制流与共享状态，最后清理验证确保行为一致。
平滑迁移旧代码的关键不是一步到位重写，而是分阶段、有策略地推进：先让回调可被 Promise 消费，再用 async/await 统一调度，最后清理冗余逻辑。整个过程不破坏现有功能，还能逐步提升可读性与错误处理能力。
第一步：识别并封装回调函数
不是所有回调都需要立刻改写，优先处理那些具备“错误优先”签名（即第一个参数是 err）且被多处调用的函数。比如 Node.js 中的 fs.readFile、数据库 query 方法，或 Vue 项目里自定义的 this.$http.get 回调封装。
- 检查函数是否符合 (err, data) ⇒ void 的模式——这是 util.promisify 或手动 Promise 封装的前提
- 对第三方库回调，优先查文档：Mongoose、Axios、fs-extra 等现代库大多已原生支持 Promise，直接启用即可
- 对无法替换的私有回调方法，用统一模板封装：return new Promise((resolve, reject) => { oldFn(...args, (err, res) => err ? reject(err) : resolve(res)) })
第二步：渐进式替换调用链
不要从最外层入口直接重写全部逻辑。选择一个具体业务路径（例如“用户登录 → 获取权限 → 加载首页数据”），逐层将回调调用替换成 await 表达式。
- 先确保每一步返回的是 Promise，哪怕只是 Promise.resolve(data)
- 把嵌套回调里的 success/error 分支，收束到 try/catch 块中统一处理
- 保留原有参数名和注释，避免因变量重命名引入隐性 bug
- 测试时重点关注异常路径：网络失败、数据为空、JSON 解析错误等是否仍能正确冒泡
第三步：重构控制流与共享状态
回调地狱常伴随作用域混乱（如 let that = this）和流程耦合（如并行请求靠计数器协调）。async/await 让这些结构自然解耦。
- 并行请求直接用 Promise.all([fn1(), fn2()])，不再需要 results 数组 + if (results.length === 2)
- 条件分支回归正常 if/else，无需在回调里层层嵌套判断
- this 上下文自动继承，不再需要 _this、self 或箭头函数绕弯
- 中间状态变量（如 token、临时 id）可直接声明在 async 函数作用域内，逻辑更贴近人类阅读顺序
第四步：清理与验证
完成语法转换后，重点不是“看起来更现代”，而是“行为完全一致”。建议做三件事：
- 运行原有单元测试，确保所有断言仍通过；若无测试，至少手动覆盖 success / error / edge case 三种场景
- 对比旧代码与新代码的堆栈信息：错误发生时，await 版本能精准定位到出错行，而非 callback 的匿名函数位置
- 删除已废弃的回调参数（如 callback、done）、重复的错误日志、冗余的 loading 状态切换逻辑
