用 util.promisify 包装回调函数最省事
Node.js 8+ 自带的 util.promisify 是首选方案，它专为这种场景设计，不需手写 Promise 封装逻辑，还能自动处理常见的错误优先回调模式（(err, result) => {}）。
常见错误现象：手动封装时忘记检查 err、漏传参数、或把 undefined 当作成功结果返回。
-
util.promisify会自动忽略第一个参数（err），只 resolve 第二个及之后的值；若err存在，则 reject 对应错误 - 仅适用于标准 Node.js 风格回调（即
callback(err, data)），对自定义签名（如callback(data, err)）不适用 - 支持直接包装函数（如
fs.readFile），也支持绑定this上下文：util.promisify(fs.readFile).bind(fs)
示例：
const { promisify } = require('util');
const fs = require('fs');
const readFileAsync = promisify(fs.readFile);
readFileAsync('./config.json', 'utf8')
.then(data => console.log(JSON.parse(data)))
.catch(err => console.error('读取失败:', err.message));
手写 Promise 封装时必须检查 err 参数位置
不是所有回调都遵循 (err, data) 模式。比如某些旧库用 (data, err)，或只传一个参数（callback(result)），这时 util.promisify 会失效，必须手写。
容易踩的坑：直接把回调的全部参数无差别 resolve，导致错误被当成正常数据返回。
- 先确认原始回调的签名——查文档、看源码、或加
console.log(arguments)实测 - 若回调是
(data, err)形式，需手动判断第二个参数是否为Error实例或非 null - 若回调只传一个参数且无显式错误机制（如某些 EventEmitter 回调），需额外约定“假值表示失败”或自行注入错误兜底
示例（适配 (data, err)）：
function promisifyDataFirst(fn, ...args) {
return new Promise((resolve, reject) => {
fn(...args, (data, err) => {
if (err != null) reject(err);
else resolve(data);
});
});
}
Promise 封装后要注意错误链和堆栈丢失
原生回调出错时堆栈通常包含调用位置；但 Promise 封装后，尤其多层 .then() 嵌套，错误堆栈可能被截断或指向 Promise.then 内部。
性能影响：每次封装都会新增一层函数调用和 Promise 实例，高频调用（如网络请求中间件）需注意内存分配压力。
- 在 Node.js 12+ 中启用
--async-stack-traces可改善异步堆栈可读性 - 避免在循环中反复调用
promisify，应提前封装一次复用：const statAsync = promisify(fs.stat);而非每次promisify(fs.stat)(path) - 若原始函数本身已支持 Promise（如
fs.promises.readFile），优先用原生实现，而非二次封装
兼容性边界：老版本 Node.js（arguments
Node.js util.promisify，但也不能简单用 function() { return new Promise(...) } 硬套——因为旧版 V8 对 arguments 的处理有性能陷阱，且严格模式下 arguments.callee 被禁用。
使用场景：维护遗留项目、嵌入式 Node 运行时、或需要精准控制 Promise 构造行为时。
- 别用
arguments动态转发参数，改用剩余参数...args（需 Node.js ≥ 6.0，且确保代码未被 Babel 转译成arguments） - 若必须支持 Node.js 4.x，用数组展开：
fn.apply(this, args.concat([callback])) - 拒绝给回调函数传
thisArg的 API（如部分 C++ 插件）需显式绑定：fn.bind(context)
真正麻烦的从来不是 Promise 语法本身，而是你不确定那个回调到底把错误塞在第几个参数里，以及它会不会在某个极端路径下根本不调用回调。
