这个终端日志是 Node JS 异步特性的结果吗？答案

【问题标题】：Is this terminal-log the consequence of the Node JS asynchronous nature?这个终端日志是 Node JS 异步特性的结果吗？
【发布时间】：2021-06-23 08:39:45
【问题描述】：

我没有找到任何具体的信息，这不是一个真正的问题，但我想更好地了解这里发生了什么。

基本上，我正在测试一些简单的 NodeJS 代码，如下所示：

//Summary : Open a file , write to the file, delete the file.

let fs = require('fs');

fs.open('mynewfile.txt' , 'w' , function(err,file){
    if(err) throw err;
    console.log('Created file!')
})

fs.appendFile('mynewfile.txt' , 'Depois de ter criado este ficheiro com o fs.open, acrescentei-lhe data com o fs.appendFile' , function(err){
    if (err) throw err;
    console.log('Added text to the file.')
})

fs.unlink('mynewfile.txt', function(err){
    if (err) throw err;
        console.log('File deleted!')
})

console.log(__dirname);

我以为这段代码会按照从上到下的顺序执行，但是当我查看终端时，我不确定是否是这种情况，因为这是我得到的：

$ node FileSystem.js 
C:\Users\Simon\OneDrive\Desktop\Portfolio\Learning Projects\NodeJS_Tutorial
Created file!
File deleted!
Added text to the file.

//Expected order would be: Create file, add text to file , delete file , log dirname.

最终，当我查看我的文件夹时，代码顺序似乎仍以某种方式被遵循，因为该文件已被删除，而我的目录中没有任何内容。

所以，我想知道，为什么终端没有按照代码从上到下编写的顺序登录。这是 NodeJS 异步特性的结果还是其他原因？

【问题讨论】：

基本上，是的。您需要使用then 或async await 来确保正确的顺序。如果您的用例非常基础，您可以改用sync functions 或fs-sync 库。

标签： node.js asynchronous console.log

【解决方案1】：

你可以这样写（未经测试）：

let fs = require('fs');

const main = async () => {
  await fs.open('mynewfile.txt' , 'w');
  await fs.appendFile('mynewfile.txt' , 'content');
  await fs.unlink('mynewfile.txt');
});

main()
  .then(() => console.log('success'()
  .catch(console.error);

或在另一个异步函数中：

const someOtherFn = async () => {
   try{
      await main();
   } catch(e) {
     // handle any rejection to your liking
   }
}

(catch 块不是强制性的。您可以选择让它们扔到顶部。这只是为了展示 async / await 如何让您使同步代码看起来好像是同步代码而不会陷入回调地狱。 )

【讨论】：

我认为通过require('fs') 你仍然可以得到 fs-API 的回调形式。所以await fs.open()在你使用的时候会抛出一个关于丢失回调的错误

【解决方案2】：

正如您所说，代码（原则上）是从上到下执行的。但是fs.open、fs.appendFile 和fs.unlink 是异步的。即，它们以特定顺序放置在执行堆栈上，但无法保证它们以何种顺序完成，因此您无法保证回调以何种顺序执行。如果多次运行代码，很有可能会遇到不同的执行顺序...

如果您需要特定的订单，您有两种不同的选择

你只在前面的回调中调用后面的操作，即如下所示

fs.open('mynewfile.txt' , 'w' , function(err,file){
  if(err) throw err;
  console.log('Created file!')

  fs.appendFile('mynewfile.txt' , '...' , function(err){
    if (err) throw err;
    console.log('Added text to the file.')

    fs.unlink('mynewfile.txt', function(err){
      if (err) throw err;
      console.log('File deleted!')
    })
  })
})

你看，随着嵌套的增加，代码变得非常丑陋且难以阅读......

您切换到基于承诺的方法

let fs = require('fs').promises;

fs.open("myfile.txt", "w")
  .then(file=> {
    return fs.appendFile("myfile.txt", "...");
  })
  .then(res => {
    return fs.unlink("myfile");
  })
  .catch(e => {
     console.log(e);
  })

有了promise-version的操作，你也可以使用async/await

async function doit() {
   let file = await fs.open('myfile.txt', 'w');
   await fs.appendFile('myfile.txt', '...');
   await fs.unlink('myfile.txt', '...');
}

对于所有三种可能性，您可能需要先关闭文件，然后才能取消链接。

有关更多详细信息，请阅读 Promises、async/await 和 Javascript 中的执行堆栈

【讨论】：

【解决方案3】：

这是两件事的结合：

Node.js 的异步特性，正如您正确假设的那样
能够取消链接打开的文件

可能发生的事情是这样的：

文件同时打开和创建（open 带有标志w）
第二次打开文件以进行追加 (fs.appendFile)
文件已取消链接
数据已附加到文件中（虽然它已经取消链接）并且文件已关闭

在追加数据时，该文件仍作为 inode 存在于磁盘上，但对其的硬链接（引用）为零。它仍然会占用空间，但操作系统会在关闭时检查引用计数，并在计数降至零时释放空间。

人们有时会在使用日志轮换的 HTTP 服务器等守护进程中遇到类似情况：如果在切换日志时出现问题，旧的日志文件可能未链接但未关闭，因此它永远不会被清理并占用空间永远（直到您重新启动或重新启动该过程）。

请注意，您观察到的操作顺序是随机的，它们可能会被重新排序。不要依赖它。

【讨论】：