我正在编写一个类似于 Notepad++ 或 UltraEdit 的迷你编辑器组件，它需要监视用户打开的文件——它有点粘糊糊，但这就是它需要的方式。
使用多个 FileSystemWatcher 实例来监视打开的文件是否明智——再次像 Notepad++ 或 UltraEdit 一样，还是有更好的方法来管理这些文件？
文档关闭后，它们将被妥善处理。
抱歉，另一件事是，为驱动器创建一个通用的 FileSystemWatcher 并监视它，然后只在我知道它是正确的文件后才向他们显示重新加载文件的消息会更明智吗？还是重启了？
您不会遇到多个 FileSystemWatchers 的问题，而且真的没有任何其他方法可以解决这个问题。
为了提高性能，请务必指定尽可能窄的过滤器。
FileSystemWatcher 有一个缺点，它会锁定被监视的文件夹，因此，例如，如果您正在观看可移动存储上的文件，它会阻止“安全设备删除”。
您可以尝试通过SHChangeNotifyRegister使用 Shell 通知。在这种情况下，您将有一个用于所有更改的入口点（或多个，如果您愿意），但在这种情况下，您将需要一些本机 shell 互操作。
这取决于可能的用例。
如果用户要打开同一个目录中的多个文件并且可能不修改任何其他内容，那么如果文件数量很大，则该目录的单个观察者可能比每个文件一个观察者更轻松。
你会发现的唯一方法是通过基准测试。当然，每个文件做一个会使观察者的生命周期更简单，所以这应该是你的第一种方法。请注意，观察者在系统线程池上触发他们的事件，因此多个观察者可以同时触发（这可能会影响您的设计）
我当然不会为每个驱动器做一个观察者，即使使用积极的过滤，你也会付出更多的努力。
如果必须，使用多个观察者很好。正如评论 ShuggyCoUk 所说，如果您的所有文件都在同一个文件夹中，您可以通过将文件观察器合并为一个来进行优化。
在更高的文件夹（例如驱动器的根目录）上创建文件监视程序可能是不明智的，因为现在您的代码必须处理因文件系统中发生的其他更改而触发的更多事件，并且进入缓冲区相当容易如果您的代码不足以处理事件，则溢出。
更少文件观察器的另一个论点是，文件系统观察器是本机对象，它固定内存。因此，根据应用程序的生命周期和大小，您可能会遇到内存碎片问题，具体方法如下：
每当您打开文件时，您的代码都会运行很长时间（例如数小时或数天），它会在内存中创建一些数据块并实例化文件观察器。然后你清理这个临时数据但是文件观察器仍然存在，如果你重复多次（而不关闭文件，或者忘记处理观察器）你刚刚在虚拟内存中创建了多个不能被 CLR 移动的对象，并且可能会陷入内存拥塞。请注意，如果您周围有几个观察者，这没什么大不了的，但如果您怀疑自己可能会进入数百个或更多观察者，请注意这将成为一个主要问题。