摘要：引言本期精讀的文章是，探討如何監(jiān)聽文件的變化。概述使用使用內(nèi)置函數(shù)似乎可以解決問題但你可能會發(fā)現(xiàn)這個回調(diào)執(zhí)行有一定延遲，因為是通過輪詢檢測文件變化的，它并不能實時作出反饋，而且只能監(jiān)聽一個文件，存在效率問題。

本期精讀的文章是：How to Watch for Files Changes in Node.js，探討如何監(jiān)聽文件的變化。

如果想使用現(xiàn)成的庫，推薦 chokidar 或 node-watch，如果想了解實現(xiàn)原理，請往下閱讀。

使用 fs 內(nèi)置函數(shù) watchfile 似乎可以解決問題：

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

但你可能會發(fā)現(xiàn)這個回調(diào)執(zhí)行有一定延遲，因為 watchfile 是通過輪詢檢測文件變化的，它并不能實時作出反饋，而且只能監(jiān)聽一個文件，存在效率問題。

使用 fs 的另一個內(nèi)置函數(shù) watch 是更好的選擇：

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

watch 通過操作系統(tǒng)提供的文件更改通知機制，在 Linux 操作系統(tǒng)使用 inotify，在 macOS 系統(tǒng)使用 FSEvents,在 windows 系統(tǒng)使用 ReadDirectoryChangesW，而且可以用來監(jiān)聽目錄的變化，在監(jiān)聽文件夾的場景中，比創(chuàng)建 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

但當我們修改一個文件時，回調(diào)卻執(zhí)行了 4 次！原因是文件被寫入時，可能觸發(fā)多次寫操作，即使只保存了一次。但我們不需要這么敏感的回調(diào)，因為通常認為一次保存就是一次修改，系統(tǒng)底層寫了幾次文件我們并不關心。

因而可以進一步判斷是否觸發(fā)狀態(tài)是 change:

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

這樣做可以一定程度解決問題，但作者發(fā)現(xiàn) Raspbian 系統(tǒng)不支持 rename 事件，如果歸類為 change，會導致這樣的判斷毫無意義。

作者要表達的意思是，在不同平臺下，fs.watch 的規(guī)則可能會不同，原因是 fs.watch 分別使用了各平臺提供的 api，所以無法保證這些 api 實現(xiàn)規(guī)則的統(tǒng)一性。

基于 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 個，但依然存在問題。我們認為文件內(nèi)容變化才算有修改，但操作系統(tǒng)考慮的因素更多，所以我們再嘗試對比文件內(nèi)容是否變化。

筆者補充：另外一些開源編輯器可能先清空文件再寫入，也會影響到觸發(fā)回調(diào)的次數(shù)。

只有文件內(nèi)容變化了，才認為觸發(fā)了改動，這下總可以了吧：

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 個，為什么多出一個？可能的原因是，在文件保存過程中，系統(tǒng)可能會觸發(fā)多個回調(diào)事件，也許存在中間態(tài)。

我們嘗試延遲 100 毫秒進行判斷，也許能避開中間狀態(tài)：

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 函數(shù)控制觸發(fā)頻率，才將觸發(fā)頻率修正。

而且我們需要結(jié)合 md5 與延遲機制共同作用，才能得到相對精準的結(jié)果：

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`);
  }
});

作者討論了一些實現(xiàn)文件夾監(jiān)聽的基本方式，可以看出，使用了各平臺原生 API 的 fs.watch 并不那么靠譜，但這也我們監(jiān)聽文件的唯一手段，所以需要基于它進行一系列優(yōu)化。

而實際場景中，還需要考慮區(qū)分文件夾與文件、軟連接、讀寫權(quán)限等情況。

另外用在生產(chǎn)環(huán)境的庫，也基本使用 50 到 100 毫秒解決重復觸發(fā)的問題。

所以無論 chokidar 或 node-watch，都大量使用了文中提及的技巧，再加上對邊界條件的處理，對軟連接、權(quán)限等情況處理，將所有可能情況都考慮到，才能提供較為準確的回調(diào)。

比如判斷文件寫入操作是否完畢，也需要通過輪詢的方式：

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 庫都采取不信任操作系統(tǒng)回調(diào)的方式，根據(jù)文件信息完全重寫了判斷邏輯。

可見，信任操作系統(tǒng)的回調(diào)，就無法抹平所有操作系統(tǒng)間的差異，唯有統(tǒng)一重寫文件的 “寫入”、“刪除”、“修改” 等邏輯，才能保證在全平臺的兼容性。

利用 nodejs 監(jiān)聽文件夾變化很容易，但提供準確的回調(diào)卻很難，主要難在兩點：

抹平操作系統(tǒng)間的差異，這需要在結(jié)合 fs.watch 的同時，增加一些額外校驗機制與延時機制。

分清楚操作系統(tǒng)預期與用戶預期，比如編輯器的額外操作、操作系統(tǒng)的多次讀寫都應該被忽略，用戶的預期不會那么頻繁，會忽略極小時間段內(nèi)的連續(xù)觸發(fā)。

另外還有兼容性、權(quán)限、軟連接等其他因素要考慮，fs.watch 并不是一個開箱可用的工程級別 api。

討論地址是：精讀《如何利用 Nodejs 監(jiān)聽文件夾》 · Issue #87 · dt-fe/weekly

如果你想?yún)⑴c討論，請點擊這里，每周都有新的主題，周末或周一發(fā)布。