FileSystemWatcher 不可靠因依赖 ReadDirectoryChangesW 且缓冲区溢出、权限变更等会导致静默失效；应视作一次性对象，定时检测+重建+日志自检。
为什么 FileSystemWatcher 经常“掉监控”
它不是为高可靠性服务设计的——底层依赖 Windows API 的 `ReadDirectoryChangesW`，一旦缓冲区溢出、权限变化、网络驱动器断连或进程被系统资源限制（比如 .NET 进程被挂起），FileSystemWatcher 就会静默停止通知，且 EnableRaisingEvents 仍为 true，你完全感知不到。
常见错误现象：Error 事件没触发、Changed 事件突然断发、重启服务后首次扫描漏掉已存在的文件。
- 务必订阅
Error事件，并在回调里记录日志 + 立即重建实例 - 设置
InternalBufferSize至少 64KB（默认 8KB），尤其监控大量小文件时 - 避免监控 UNC 路径或映射网络驱动器；若必须用，加心跳检测（如定期
File.Exists某个已知文件） - 不要跨线程复用同一个
FileSystemWatcher实例；每次重建后重新注册事件
如何让监控不因单次异常而彻底失效
核心思路：把 FileSystemWatcher 当成一次性的短生命周期对象，而非长期运行的单例。
使用场景：Windows 服务、后台守护进程、长时间运行的 CLI 工具。
- 用
Timer每 30 秒检查Watcher是否仍在正常工作（例如：记录上次事件时间戳，超时则判定失效） - 一旦发现异常或超时，调用
Dispose()+ 新建实例 + 重新设置Path、Filter、NotifyFilter - 重建过程要加锁（
lock或AsyncLock），防止并发重建导致事件重复绑定 - 初始化时先用
Directory.GetFiles(path, filter, SearchOption.AllDirectories)做一次快照比对，补全可能遗漏的初始状态
NotifyFilter 设哪些值才真正有用
设多了会加重内核负担、增加丢事件概率；设少了又收不到关键变更。默认值（FileName | DirectoryName | Attributes | Size | LastWrite）在多数场景下反而冗余。
性能影响：每多一个过滤项，内核就要多做一次判断；Size 和 LastWrite 在大文件频繁写入时极易引发缓冲区溢出。
- 只监控文件增删？用
NotifyFilter.FileName | NotifyFilter.DirectoryName - 需要识别内容修改？优先监听
LastWrite，而不是Size（后者在追加写、稀疏文件等场景不可靠） - 绝对不要同时设
LastAccess（Windows 默认禁用该时间戳更新，且开启后影响磁盘性能） - 如果路径下有上万文件，关闭
IncludeSubdirectories，改用分层轮询 + 小范围 watcher 组合
服务级部署时最易忽略的三个点
本地调试 OK 不代表上线稳定——服务账户权限、Session 0 隔离、以及 .NET 运行时行为差异，会让监控在 Windows 服务中彻底失能。
- 服务登录账户必须对监控路径有
ReadData和Synchronize权限（仅“读取”权限不够） - 不要依赖
Console.WriteLine或未配置的日志框架输出；Windows 服务没有交互式桌面，stdout 会被丢弃 - .NET 6+ 在 Windows 服务中默认启用
ThreadPool线程限制，高频事件可能排队阻塞；可临时调大ThreadPool.SetMinThreads(100, 100)（需权衡）
真正的难点不在代码怎么写，而在你怎么确认它此刻正在工作——加一条“自检日志”，每分钟写入当前时间戳到一个固定文件，并由外部脚本校验其新鲜度。否则，你以为它活着，其实已经死了两小时。
