首页/文章/javascript

JavaScript中读取文件的各种方法

2024-09-02
13955 分钟
...

在JavaScript中,尤其是配合Node.js这样的运行时环境,有多种方式可以读取服务器上的文件。每种方法都有其适用场景和优缺点。今天,我们就来比较几种常见的文件读取方法,看看哪一种最适合你的需求。

太长不看版

如果你在寻找一个快速且简单的方法,fs.promises是一个不错的选择,它提供了一个Promise接口,让你能够以现代的异步语法来处理文件读取。然而,如果你更倾向于同步方法,你可能会更喜欢fs.readFileSync,虽然它会阻塞当前线程直到文件读取完成。最后,如果你在寻找一种能够提供更好的性能的方法,你可能会想要考虑使用fs.readFile,这是Node.js中最传统的异步文件读取方法,使用回调函数来处理结果。

使用fs.promises

const fs = require('fs/promises'); const readFile = fs.readFile; readFile("lipsum.txt", { encoding: 'utf-8' }) .then((data) => {...}) .catch((err) => {...});

这种方法使用了Node.js提供的fs.promises接口,它返回一个Promise对象,可以链式调用.then().catch()方法来处理异步操作的结果。

使用fs.readFileutil.promisify

const fs = require('fs'); const util = require('util'); const readFile = util.promisify(fs.readFile); readFile("lipsum.txt", { encoding: 'utf-8' }) .then((data) => {...}) .catch((err) => {...});

这种方法通过util.promisify将传统的回调函数转换成返回Promise的函数,使得你可以用更现代的异步语法来处理文件读取。

使用fs.readFileSync

const fs = require('fs'); const readFileSync = fs.readFileSync; var data = readFileSync("lipsum.txt", { encoding: 'utf-8' });

这是同步方法,它会阻塞当前线程直到文件读取完成,适用于对性能要求不高且文件不大的情况。

使用awaitfs.readFileSync

const fs = require('fs'); const readFileSync = fs.readFileSync; async function f(name, options) {   return readFileSync(name, options); }

这种方法结合了async/await语法和同步读取,可以在需要同步行为但希望代码看起来更异步的情况下使用。

使用fs.readFile

const fs = require('fs'); const readFile = fs.readFile; readFile('lipsum.txt', function read(err, data) {...});

这是Node.js中最传统的异步文件读取方法,使用回调函数来处理结果。

性能比较

我进行了一项小的基准测试,重复读取磁盘上的同一个文件,并记录读取文件50,000次所需的毫秒数。文件相对较小,略多于一千字节。我使用的是一台拥有数十个Ice Lake Intel核心和大量内存的大型服务器。测试使用了Node.js 20.1和Bun 1.0.14。Bun是一个与Node.js竞争的JavaScript运行时[1]。

多次运行基准测试,我报告了所有情况下的最佳结果。你的结果可能会有所不同。

方法Node.js 时间Bun 时间
fs.promises2400 毫秒110 毫秒
fs.readFile 和 util.promisify1500 毫秒180 毫秒
fs.readFileSync140 毫秒140 毫秒
await fs.readFileSync220 毫秒180 毫秒
fs.readFile760 毫秒90 毫秒

至少在我的系统上,在这次测试中,使用Node.js时fs.promises明显比其他方法成本更高。Bun运行时在这次测试中比Node.js快得多。

结果看起来对fs.promises更不利,因为readFileSync使用了300毫秒的CPU时间,而fs.promises使用了7秒的CPU时间。这是因为fs.promises在基准测试期间触发了多个核心的工作。

将文件大小增加到32kB并不会改变结论。如果你使用更大的文件,许多Node.js的案例会因“堆限制Allocation failed”而失败。Bun即使在大文件下也能继续工作。测试结果在Bun中没有改变结论:在我的测试中,即使对于大文件,fs.readFile也是一致更快的。

本文译自:https://lemire.me/blog/2024/03/12/how-to-read-files-quickly-in-javascript/

Reference

[1]Bun是一个与Node.js竞争的JavaScript运行时: https://bun.dev/

如果您觉得这篇文章有帮助,请点个赞吧~

分享文章

相关文章

更多文章 →
javascript2026-02-24
navigator.sendBeacon全指南
在前端开发中,埋点系统是必不可少的一环。我们经常需要在用户 关闭页面 、 刷新 或 跳转路由 时,向服务器发送最后一条统计数据(比如用户停留时长、页面跳出率)。 但这看似简单的需求,在实现时却危机四伏:请求发不出去?页面跳转卡顿?今天我们就来聊聊这个问题的终极解决方案 —— 。 一、 痛点与传统方案的挣扎 场景还原 当用户点击关闭按钮时,浏览器会触发生命周期事件( 或 )。如果我们直接使用普通的异步 AJAX ( 或 ) 发送请求,浏览...
学习
javascript2025-11-02
理解浏览器事件系统,从用户点击到事件对象的完整旅程
深入理解浏览器事件系统:从用户点击到事件对象的完整旅程 “当我点击页面按钮时,背后发生了什么?为什么回调函数能收到一个包含丰富信息的event对象?今天,让我们一起揭开浏览器事件系统的神秘面纱。” 一个令人困惑的现象 作为前端开发者,我们每天都在写这样的代码: 这段代码如此熟悉,以至于我们很少停下来思考:​ ​这个 对象到底从哪里来?它为什么能知道点击的精确坐标?为什么能识别是哪个元素被点击了?​ ​ 更神奇的是,当我们手动创建事件时:...
学习
javascript2025-10-01
实现大文件上传全流程详解
在日常开发中,大文件上传是个绕不开的坎——动辄几百 MB 甚至 GB 级的文件,直接上传不仅容易超时,还会让用户体验大打折扣。最近我用 Vue+Express 实现了一套完整的大文件上传方案,支持分片上传、断点续传、秒传和手动中。 一、先看效果:我们要实现什么? 先上核心功能清单,确保大家明确目标,知道我们要解决哪些实际问题: 大文件分片上传 :将文件切成固定大小的小片段分批上传,避免单次请求超时 秒传 :服务器已存在完整文件时,直接返...
学习
javascript2025-09-18
JavaScript 的多线程能力:Worker
如果你写过一些计算量稍大的 JavaScript 代码,比如图像处理、大量数据排序或者复杂的算法,你几乎肯定遇到过浏览器“卡死”的现象。点击页面没反应,动画也停了,就像整个世界都静止了。 这就是主线程被阻塞的典型后果。因为主线程既要负责执行 JavaScript,又要负责渲染页面、响应用户操作,一旦它被繁重的计算任务占满,就无暇顾及其他,用户体验便直线下降。 这个问题的根源,正是“主线程是单线程的”。那么,如何解决呢? 答案很简单:把这...
学习面试
javascript2025-09-15
一张 8K 海报差点把首屏拖垮
你给后台管理系统加了一个「企业风采」模块,运营同学一口气上传了 200 张 8K 宣传海报。首屏直接飙到 8.3 s,LCP 红得发紫。 老板一句「能不能像朋友圈那样滑到哪看到哪?」——于是你把懒加载重新翻出来折腾了一轮。 解决方案:三条技术路线,你全踩了一遍 1\. 最偷懒:原生 一行代码就能跑,浏览器帮你搞定。 🔍 关键决策点 2020 年后现代浏览器全覆盖,IE 全军覆没。 必须写死 ,否则 CLS 会抖成 PPT。 适用场景...
学习
javascript2025-09-10
🚀 Web Worker让你的应用丝滑
🌟 引言 在日常的前端开发中,你是否遇到过这样的困扰: 大数据处理时页面卡死 :处理几万条数据时,页面直接卡成PPT,用户点击毫无反应 复杂计算阻塞UI :图片处理、数据分析等计算密集型任务让整个应用假死 文件上传/下载卡顿 :大文件操作时,其他功能完全无法使用 实时数据处理性能差 :WebSocket接收大量数据时,页面渲染严重滞后 今天分享6个Web Worker的核心技巧,让你的应用告别卡顿,用户体验丝滑如德芙! 💡 核心技巧...
学习

评论

请登录后发表评论

去登录
加载评论中...

目录