FileSystemWatcher监测子目录首次变更后为何停止工作

你遇到的是FileSystemWatcher最容易被忽略的默认行为：

• FileSystemWatcher的所有事件都在线程池线程上调度，只要任意事件处理委托（OnCreated/OnDeleted/OnRenamed/OnChanged）抛出未捕获的异常，监听器会直接终止所有后续事件的触发，不会自动恢复，也不会默认触发Error事件。
• 你的故障表现完全匹配这个行为：根目录下文件变更时，事件处理逻辑运行正常，所以监听器持续工作；子目录下文件变更触发事件时，你的处理逻辑抛出了异常，直接导致监听器停摆。
• 你观察到的回车后延迟打印现象也符合这个场景：抛出未捕获异常的线程池线程会被运行时销毁，后续触发控制台输出操作时，线程池需要重新创建新的工作线程，这个冷启动过程通常会有2~5秒的延迟。

1. 给所有事件处理方法加全局异常兜底
   绝对不要让任何异常逃出事件处理委托的作用域，先把异常打出来定位具体报错点：

   private void OnChanged(object sender, FileSystemEventArgs e)
   {
       try
       {
           // 原有变更记录逻辑
       }
       catch (Exception ex)
       {
           Console.WriteLine($"处理{e.ChangeType}事件失败，路径：{e.FullPath}，错误：{ex}");
       }
   }
   // OnCreated/OnDeleted/OnRenamed 都按同样方式加try-catch兜底
   

   重点排查路径处理相关逻辑：根目录下触发事件时e.Name是纯文件名，子目录下触发事件时e.Name是带目录层级的相对路径（比如subdir\test.txt），如果你的逻辑默认e.Name不包含路径分隔符，做路径拼接、文件名解析的时候就会在子目录场景下抛出异常，这是这类故障最高发的诱因。

2. 补全Error事件处理逻辑
   不要留空OnError方法，监听器内部错误（包括缓冲区溢出、权限异常、内部状态失效）都会触发这个事件，可以在这里第一时间感知监听器状态：

   private void OnError(object sender, ErrorEventArgs e)
   {
       Console.WriteLine($"监听器内部错误：{e.GetException()}");
       // 必要时可以在这里重新初始化监听器恢复监控
   }
   

3. 确认监听器实例引用持有
   确保CreateFileSystemWatcher返回的实例被赋值给类的长生命周期字段，不要作为局部变量被GC回收，不过这个问题不会精准在子目录操作后触发，属于常规排查项。
   你目前不需要调整InternalBufferSize参数，你已经排除了高频操作触发缓冲区溢出的场景，默认缓冲区大小足够应对普通使用。

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