为何Promise的resolve中调用unlink的两种写法均生效？

首先明确核心前提：当CSV流的end事件触发时，文件已经完全读取完毕，流相关的文件描述符已经被释放，此时执行文件删除操作unlink不会因为文件被占用而失败，这是两种写法都能正常运行的基础。

接下来分别拆解两种写法的逻辑：

写法一：先调用unlink再resolve #

.on('end', () => {
  unlink(file); 
  resolve();
})

• unlink(file)是fs/promises提供的异步方法，调用后会立即返回一个Promise，但这里没有等待它完成就直接调用了resolve()。
• 这意味着collectKeywords函数返回的Promise会立即进入resolved状态，而文件删除操作会在后台异步执行。
• 之所以不会出问题，是因为文件已经读取完成，没有被任何进程占用，所以后台的删除操作能顺利完成，不会报错。

写法二：resolve接收unlink返回的Promise #

.on('end', () => {
  resolve(unlink(file));
})

• 根据Promise的规则，resolve()如果接收的是另一个Promise对象，会自动等待这个Promise完成（成功或失败），再让外层的Promise进入对应状态。
• 也就是说，collectKeywords返回的Promise会等待文件删除操作完成后才进入resolved状态。
• 同样因为文件已经读取完毕，unlink操作不会遇到文件占用的问题，所以整个流程能正常走完。

潜在差异（你没遇到但需要注意） #

• 写法一中，如果unlink意外失败（比如文件被其他进程临时占用），这个错误不会被collectKeywords的Promise捕获，相当于“静默失败”；
• 写法二中，如果unlink失败，错误会被传播到外层的Promise，你可以通过try/catch或者.catch()捕获这个错误。

内容的提问来源于stack exchange，提问作者Álvaro