本文解析 Node.js 中 readFile 等异步 API 导致的执行顺序问题，展示如何通过回调函数、Promise 封装及 async/await 语法解决异步数据获取与返回值不同步的常见陷阱，帮助开发者掌握现代 JS 异步编程最佳实践。
问题背景
在技术交流群中，开发者经常讨论关于异步处理的各种疑问。针对近期出现的一个典型场景，这里进行具体解答。
该问题的核心现象如下：
观察以下代码片段，其预期输出结果为 456，但实际运行却输出了 []。造成这一现象的原因是：return demo 函数不会阻塞后续代码的执行，而是等待文件读取完成的回调触发。因此，[] 会优先于回调执行，此时变量 demo 的值仍为 。
const fs = require('fs')
const readFileFn = () => {
let demo = []
fs.readFile('./config.json', async function (err, date) {
Promise.all([Promise.resolve(() => 456)]).then(res => {
demo = res
})
})
return demo
}
console.log('end', readFileFn()) // 要输出456
这是 Node.js 中非常典型的异步编程问题。针对此问题，存在多种解决思路，接下来我们将逐一探讨。
- 既然 API 提供了回调函数机制来执行文件读取完成后的逻辑，我们也可以采用相同的模式，通过传入回调函数来处理读取结束后的操作。
const fs = require('fs')
const readFileFn = (callback) => {
fs.readFile('./config.json', async function (err, date) {
Promise.all([Promise.resolve(456)]).then(res => {
callback(res)
})
})
}
readFileFn(data => console.log(data)) // [ 456 ]
- 在现代 JavaScript 开发中，Promise 风格更为流行。结合 async/await 语法，可以进一步简化异步代码的编写与阅读。
const fs = require('fs')
const readFileFn = async () => {
const [result] = await Promise.all([
new Promise(resolve => fs.readFile('./config.json', (err, data) => resolve(456))),
])
return result
}
readFileFn().then(res => console.log(res)) // 456
在上述方案中，我们手动创建了一个 Promise 对象。当 的回调函数被执行时，调用 resolve 方法使 Promise 状态变为已完成（resolved），此时 Promise 才算真正结束。
- 此外，我们还可以直接让封装后的 readFileFn 函数返回一个 Promise 对象，从而简化调用逻辑。
const readFileFn = () => {
return new Promise(resolve => {
fs.readFile('./config.json', async function (err, date) {
Promise.all([Promise.resolve(456)]).then(res => {
resolve(res)
})
})
})
}
readFileFn().then(console.log) // [456]
// readFileFn().then(res => console.log(res))
总结
在 Node.js 中，存在大量类似 readFile 的 API，它们最初采用回调函数来实现异步操作。随着技术发展，出现了 Promise 和 async/await 等更先进的异步方案。现代 JavaScript 编程鼓励使用这些新方案，它们与传统的回调函数机制完全兼容。
以上便是关于 Node.js API 异步问题解决的详细分析，如需了解更多相关技术资料，请持续关注本站后续文章。