JavaScript中将Node.js风格的(err, result)回调函数转为Promise，最基础方式是用Promise构造函数手动封装，推荐使用Node.js 8.0+内置的util.promisify，它自动处理this绑定、多参数回调等边界情况。
JavaScript 中将传统的“毁掉函数”（即回调地狱中的错误优先回调函数，俗称 Node.js 风格的 (err, result) => {...} 函数）包装为 Promise，核心是用 Promise 构造函数封装调用逻辑，并在回调中根据 err 决定 resolve 还是 reject。
使用 Promise 构造函数手动包装
这是最基础、最可控的方式。适用于任意符合 (err, data) => {} 签名的函数（如 Node.js 原生 API：fs.readFile、dns.lookup 等）。
- 创建新 Promise，在执行器函数中调用原函数
- 若
err存在，调用reject(err) - 否则调用
resolve(data)
示例：
function promisify(readFile) {
return function(...args) {
return new Promise((resolve, reject) => {
readFile(...args, (err, data) => {
if (err) reject(err);
else resolve(data);
});
});
};
}
// 使用
const fs = require('fs');
const readFileAsync = promisify(fs.readFile);
readFileAsync('./data.txt', 'utf8')
.then(content => console.log(content))
.catch(err => console.error(err));
使用 util.promisify（推荐，Node.js 8.0+）
Node.js 内置的 util.promisify 是标准、安全、已优化的方案，自动处理常见边界（如 this 绑定、多参数回调等）。
立即学习“Java免费学习笔记（深入）”；
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 直接传入函数即可返回 Promise 版本
- 原函数必须满足「最后一个参数是回调，且回调形参为
(err, ...values)」 - 支持为函数挂载
util.promisify.custom自定义行为
示例：
const { promisify } = require('util');
const fs = require('fs');
const readFileAsync = promisify(fs.readFile);
const statAsync = promisify(fs.stat);
readFileAsync('./config.json', 'utf8')
.then(JSON.parse)
.then(console.log)
.catch(console.error);
处理多参数回调或非标准签名
有些老函数回调返回多个成功值（如 (err, val1, val2)），默认 promisify 只 resolve 第一个成功值。需要自定义时可：
- 手动包装，显式 resolve 数组或对象
- 或利用
util.promisify.custom静态方法指定行为
例如手动处理双值回调：
function promisifyTwo(readFile) {
return function(...args) {
return new Promise((resolve, reject) => {
readFile(...args, (err, a, b) => {
if (err) reject(err);
else resolve({ a, b }); // 或 resolve([a, b])
});
});
};
}
注意事项与常见陷阱
包装时需留意以下细节，避免隐性错误：
- 确保回调只被调用一次：原函数不能重复触发回调，否则 Promise 状态不可逆，多余调用会被忽略
-
this 上下文问题：手动包装时注意绑定
this（如readFile.call(this, ...)），util.promisify会自动保留 - 不支持同步抛错的函数：如果原函数可能同步抛异常（而非走回调），需额外 try/catch 包裹
-
错误类型建议保持原样：不要把
err包成新 Error，便于下游 stack trace 追踪
