精读《如何利用 Nodejs 监听文件夹》

1 引言

本期精读的文章是:How to Watch for Files Changes in Node.js,探讨如何监听文件的变化。

如果想使用现成的库,推荐 chokidarnode-watch,如果想了解实现原理,请往下阅读。

2 概述

使用 fs.watchfile

使用 fs 内置函数 watchfile 似乎可以解决问题:

fs.watchFile(dir, (curr, prev) => {});

但你可能会发现这个回调执行有一定延迟,因为 watchfile 是通过轮询检测文件变化的,它并不能实时作出反馈,而且只能监听一个文件,存在效率问题。

使用 fs.watch

使用 fs 的另一个内置函数 watch 是更好的选择:

fs.watch(dir, (event, filename) => {});

watch 通过操作系统提供的文件更改通知机制,在 Linux 操作系统使用 inotify,在 macOS 系统使用 FSEvents,在 windows 系统使用 ReadDirectoryChangesW,而且可以用来监听目录的变化,在监听文件夹的场景中,比创建 N 个 fs.watchfile 效率高出很多。

$ node file-watcher.js
[2018-05-21T00:55:52.588Z] Watching for file changes on ./button-presses.log
[2018-05-21T00:56:00.773Z] button-presses.log file Changed
[2018-05-21T00:56:00.793Z] button-presses.log file Changed
[2018-05-21T00:56:00.802Z] button-presses.log file Changed
[2018-05-21T00:56:00.813Z] button-presses.log file Changed

但当我们修改一个文件时,回调却执行了 4 次!原因是文件被写入时,可能触发多次写操作,即使只保存了一次。但我们不需要这么敏感的回调,因为通常认为一次保存就是一次修改,系统底层写了几次文件我们并不关心。

因而可以进一步判断是否触发状态是 change:

fs.watch(dir, (event, filename) => {
  if (filename && event === "change") {
    console.log(`${filename} file Changed`);
  }
});

这样做可以一定程度解决问题,但作者发现 Raspbian 系统不支持 rename 事件,如果归类为 change,会导致这样的判断毫无意义。

作者要表达的意思是,在不同平台下,fs.watch 的规则可能会不同,原因是 fs.watch 分别使用了各平台提供的 api,所以无法保证这些 api 实现规则的统一性。

优化方案一:对比文件修改时间

基于 fs.watch,增加了对修改时间的判断:

let previousMTime = new Date(0);

fs.watch(dir, (event, filename) => {
  if (filename) {
    const stats = fs.statSync(filename);
    if (stats.mtime.valueOf() === previousMTime.valueOf()) {
      return;
    }
    previousMTime = stats.mtime;
    console.log(`${filename} file Changed`);
  }
});

log 由 4 个变成了 3 个,但依然存在问题。我们认为文件内容变化才算有修改,但操作系统考虑的因素更多,所以我们再尝试对比文件内容是否变化。

笔者补充:另外一些开源编辑器可能先清空文件再写入,也会影响到触发回调的次数。

优化方案二:校验文件 md5

只有文件内容变化了,才认为触发了改动,这下总可以了吧:

let md5Previous = null;

fs.watch(dir, (event, filename) => {
  if (filename) {
    const md5Current = md5(fs.readFileSync(buttonPressesLogFile));
    if (md5Current === md5Previous) {
      return;
    }
    md5Previous = md5Current;
    console.log(`${filename} file Changed`);
  }
});

log 终于由 3 个变成了 2 个,为什么多出一个?可能的原因是,在文件保存过程中,系统可能会触发多个回调事件,也许存在中间态。

优化方案三:加入延迟机制

我们尝试延迟 100 毫秒进行判断,也许能避开中间状态:

let fsWait = false;
fs.watch(dir, (event, filename) => {
  if (filename) {
    if (fsWait) return;
    fsWait = setTimeout(() => {
      fsWait = false;
    }, 100);
    console.log(`${filename} file Changed`);
  }
});

这下 log 变成一个了。很多 npm 包在这里使用了 debounce 函数控制触发频率,才将触发频率修正。

而且我们需要结合 md5 与延迟机制共同作用,才能得到相对精准的结果:

let md5Previous = null;
let fsWait = false;
fs.watch(dir, (event, filename) => {
  if (filename) {
    if (fsWait) return;
    fsWait = setTimeout(() => {
      fsWait = false;
    }, 100);
    const md5Current = md5(fs.readFileSync(dir));
    if (md5Current === md5Previous) {
      return;
    }
    md5Previous = md5Current;
    console.log(`${filename} file Changed`);
  }
});

3 精读

作者讨论了一些实现文件夹监听的基本方式,可以看出,使用了各平台原生 API 的 fs.watch 并不那么靠谱,但这也我们监听文件的唯一手段,所以需要基于它进行一系列优化。

而实际场景中,还需要考虑区分文件夹与文件、软连接、读写权限等情况。

另外用在生产环境的库,也基本使用 50 到 100 毫秒解决重复触发的问题。

所以无论 chokidarnode-watch,都大量使用了文中提及的技巧,再加上对边界条件的处理,对软连接、权限等情况处理,将所有可能情况都考虑到,才能提供较为准确的回调。

比如判断文件写入操作是否完毕,也需要通过轮询的方式:

function awaitWriteFinish() {
  // ...省略
  fs.stat(
    fullPath,
    function(err, curStat) {
      // ...省略

      if (prevStat && curStat.size != prevStat.size) {
        this._pendingWrites[path].lastChange = now;
      }

      if (now - this._pendingWrites[path].lastChange >= threshold) {
        delete this._pendingWrites[path];
        awfEmit(null, curStat);
      } else {
        timeoutHandler = setTimeout(
          awaitWriteFinish.bind(this, curStat),
          this.options.awaitWriteFinish.pollInterval
        );
      }
    }.bind(this)
  );
  // ...省略
}

可以看出,第三方 npm 库都采取不信任操作系统回调的方式,根据文件信息完全重写了判断逻辑。

可见,信任操作系统的回调,就无法抹平所有操作系统间的差异,唯有统一重写文件的 “写入”、“删除”、“修改” 等逻辑,才能保证在全平台的兼容性。

4 总结

利用 nodejs 监听文件夹变化很容易,但提供准确的回调却很难,主要难在两点:

  1. 抹平操作系统间的差异,这需要在结合 fs.watch 的同时,增加一些额外校验机制与延时机制。
  2. 分清楚操作系统预期与用户预期,比如编辑器的额外操作、操作系统的多次读写都应该被忽略,用户的预期不会那么频繁,会忽略极小时间段内的连续触发。

另外还有兼容性、权限、软连接等其他因素要考虑,fs.watch 并不是一个开箱可用的工程级别 api。

5 更多讨论

讨论地址是:精读《如何利用 Nodejs 监听文件夹》 · Issue #87 · dt-fe/weekly

如果你想参与讨论,请点击这里,每周都有新的主题,周末或周一发布。


前端精读专栏
精读前端业界好文,每周更新
6.9k 声望
9.5k 粉丝
0 条评论
推荐阅读
可视化搭建 - 组件值校验
组件值校验,即在组件值变化时判断是否满足校验逻辑,若不满足校验逻辑,可以拿到校验错误信息进行错误提示或其他逻辑处理。声明 valueValidator 可开启值校验: {代码...} 如上面的例子,相当于对组件值做了 “不...

黄子毅阅读 225

正则表达式实例
收集在业务中经常使用的正则表达式实例,方便以后进行查找,减少工作量。常用正则表达式实例1. 校验基本日期格式 {代码...} {代码...} 2. 校验密码强度密码的强度必须是包含大小写字母和数字的组合,不能使用特殊...

寒青56阅读 8.4k评论 11

JavaScript有用的代码片段和trick
平时工作过程中可以用到的实用代码集棉。判断对象否为空 {代码...} 浮点数取整 {代码...} 注意:前三种方法只适用于32个位整数,对于负数的处理上和Math.floor是不同的。 {代码...} 生成6位数字验证码 {代码...} ...

jenemy48阅读 6.9k评论 12

从零搭建 Node.js 企业级 Web 服务器(十五):总结与展望
总结截止到本章 “从零搭建 Node.js 企业级 Web 服务器” 主题共计 16 章内容就更新完毕了,回顾第零章曾写道:搭建一个 Node.js 企业级 Web 服务器并非难事,只是必须做好几个关键事项这几件必须做好的关键事项就...

乌柏木75阅读 7k评论 16

再也不学AJAX了!(二)使用AJAX ① XMLHttpRequest
「再也不学 AJAX 了」是一个以 AJAX 为主题的系列文章,希望读者通过阅读本系列文章,能够对 AJAX 技术有更加深入的认识和理解,从此能够再也不用专门学习 AJAX。本篇文章为该系列的第二篇,最近更新于 2023 年 1...

libinfs42阅读 6.8k评论 12

封面图
从零搭建 Node.js 企业级 Web 服务器(一):接口与分层
分层规范从本章起,正式进入企业级 Web 服务器核心内容。通常,一块完整的业务逻辑是由视图层、控制层、服务层、模型层共同定义与实现的,如下图:从上至下,抽象层次逐渐加深。从下至上,业务细节逐渐清晰。视图...

乌柏木45阅读 8.5k评论 6

从零搭建 Node.js 企业级 Web 服务器(二):校验
校验就是对输入条件的约束,避免无效的输入引起异常。Web 系统的用户输入主要为编辑与提交各类表单,一方面校验要做在编辑表单字段与提交的时候,另一方面接收表单的接口也要做足校验行为,通过前后端共同控制输...

乌柏木35阅读 6.6k评论 10

6.9k 声望
9.5k 粉丝
宣传栏