Node.js中持续监听文件变更的正确异步实现方式

兄弟，你遇到的这个「只触发一次监听就终止」的情况其实有点反常——因为fs.watch本身的设计就是持续监听文件/目录变更的，不会触发一次就停。大概率是踩了编辑器保存机制的坑，或者代码逻辑写岔了，我给你捋清楚正确的写法和避坑要点：

一、先纠正错误写法：别递归创建监听器 #

你之前在do_something里重新调用fs.watch的操作是错的，每触发一次变更就会新建一个监听器，不仅解决不了问题，还会导致内存泄漏（多个监听器同时跑）。正确的基础写法根本不需要递归：

const fs = require('fs');

// 定义你的业务逻辑
const doSomething = () => {
  console.log('处理文件变更的逻辑');
};

// 启动监听的函数
const startFileWatcher = () => {
  // 创建监听器
  const watcher = fs.watch('filename.txt', (eventType, filename) => {
    // 有些平台（比如Windows）可能返回undefined的filename，加个判断兜底
    if (filename) {
      console.log(`文件 ${filename} 发生了 ${eventType} 类型的变更`);
      doSomething();
    }
  });

  // 一定要监听监听器的错误事件！
  // 不然监听器遇到错误（比如文件被删除）会直接导致进程崩溃，看起来像监听终止了
  watcher.on('error', (err) => {
    console.error('监听过程出错:', err);
  });

  console.log('已启动文件监听');
};

// 启动监听
startFileWatcher();

二、为什么会出现「只触发一次」的假象？ #

最常见的原因是编辑器的「原子保存」机制：比如VS Code、Sublime这类编辑器，保存文件时不是直接修改原文件，而是先创建一个临时文件，写入内容后替换掉原文件。这时候fs.watch会触发rename事件，原文件的监听器就会失效（因为原文件被替换成新文件了）。

解决这个问题有两个方案：

方案1：监听整个目录，判断目标文件 #

把监听对象改成文件所在的目录，然后在回调里判断变更的是不是你要的文件：

fs.watch('./', (eventType, filename) => {
  // 只处理目标文件的变更
  if (filename === 'filename.txt') {
    console.log(`文件 ${filename} 变更了`);
    doSomething();
  }
});

方案2：用fs.watchFile（兼容性更好，但性能稍差） #

fs.watchFile是通过轮询文件状态来实现监听的，不会因为文件被替换就失效，适合对性能要求不高的场景：

// interval参数是轮询间隔，单位毫秒，默认5000
fs.watchFile('filename.txt', { interval: 1000 }, (currStats, prevStats) => {
  // 通过修改时间判断文件是否真的变更（避免无意义的触发）
  if (currStats.mtime.getTime() !== prevStats.mtime.getTime()) {
    console.log('文件内容确实变更了');
    doSomething();
  }
});

// 如果需要停止监听，调用unwatchFile即可
// fs.unwatchFile('filename.txt');

三、额外避坑提示 #

• 跨平台差异：fs.watch在Windows、macOS、Linux上的表现有差异，比如eventType的取值（Windows可能是change/rename，macOS可能只有change），部分平台可能返回undefined的filename，记得做兼容判断。
• 处理文件删除/移动：如果你的监听文件被删除或移动，监听器会触发error事件，一定要监听这个事件避免进程崩溃。

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