请注意，您不必将这个问题过于复杂化，再试一次就可以了。

import { promises as fs } from "fs";

const filepaths = [];
const errors = [];

function process_file(content: string) {
    // logic here
}

await Promise.all(
    filepaths.map(function read_each(filepath) {
        return fs
            .readFile(filepath, "utf8")
            .then(process_file)
            .catch(function (error) {
                if (error.code === "EMFILE") return read_each(filepath);
                else errors.push({ file: filepath, error });
            });
    }),
);

以@blak3r的回答为基础，以下是我使用的一些速记，以防它有助于其他诊断:

如果你试图调试一个正在耗尽文件描述符的node .js脚本，这里有一行给你问题节点进程使用的lsof的输出:

openFiles = child_process.execSync(`lsof -p ${process.pid}`);

这将同步运行由当前运行的Node.js进程过滤的lsof，并通过缓冲区返回结果。

然后使用console.log(openFiles.toString())将缓冲区转换为字符串并记录结果。

使用最新的fs-extra。

我在Ubuntu(16和18)上遇到了这个问题，有足够的文件/套接字描述符空间(用lsof |wc -l计数)。使用fs-extra 8.1.0版本。更新到9.0.0后，“错误:EMFILE，太多打开的文件”消失了。

我在不同操作系统的节点处理文件系统上遇到过不同的问题。文件系统显然不是简单的。

我安装了守望者，改变限制等，它不工作在Gulp。

不过，重新启动iterm2实际上有所帮助。

以下是我的观点:考虑到CSV文件只是几行文本，我已经流化了数据(字符串)以避免这个问题。

在我的用例中最简单的解决方案。

它可以与优雅fs或标准fs一起使用。请注意，在创建文件时，文件中不会有头文件。

// import graceful-fs or normal fs
const fs = require("graceful-fs"); // or use: const fs = require("fs") 

// Create output file and set it up to receive streamed data
// Flag is to say "append" so that data can be recursively added to the same file 
let fakeCSV = fs.createWriteStream("./output/document.csv", {
  flags: "a",
});

和数据，需要流到文件我已经这样做了

// create custom streamer that can be invoked when needed
const customStreamer = (dataToWrite) => {
  fakeCSV.write(dataToWrite + "\n");
};

注意，dataToWrite只是一个带有自定义分隔符“;”或“，”的字符串。 即。

const dataToWrite = "batman" + ";" + "superman"
customStreamer(dataToWrite);

这将向文件写入“batman;superman”。

请注意，在这个示例中没有错误捕获或其他任何东西。 文档:https://nodejs.org/api/fs.html # fs_fs_createwritestream_path_options

首先使用expo update更新你的expo版本，然后运行yarn / NPM install。这为我解决了问题!