FileSystemWatcher漏事件或重复触发的根本原因是依赖操作系统底层通知机制（如Windows的ReadDirectoryChangesW），该机制不保证顺序、无重试、高频率写入时天然丢包。
为什么 FileSystemWatcher 经常漏事件或触发多次
根本原因不是它“不稳定”，而是它依赖底层操作系统通知机制（Windows 是 ReadDirectoryChangesW），而该机制本身不保证事件顺序、不重试失败、且对高频率写入（如日志轮转、ZIP 解压）天然丢包。
实操建议：
- 永远启用
IncludeSubdirectories = true时，注意 NTFS 权限和符号链接可能让子目录监控静默失效 - 把
NotifyFilter设得越窄越好——比如只监NotifyFilters.LastWrite | NotifyFilters.FileName，避免属性变更（如只读位、时间戳微调）干扰主逻辑 - 必须用
BeginInvoke或Task.Run脱离事件线程处理文件内容，否则后续事件会被阻塞甚至丢失（尤其在快速连续创建+写入的场景下） - 对
Changed事件，要区分是ChangeType.Modified还是ChangeType.Created—— 很多程序误以为“改了就一定存在可读内容”，其实文件可能正被其他进程独占写入中
如何安全读取刚通知到的文件
收到 Created 或 Changed 后直接 File.OpenRead？90% 情况会抛 IOException: The process cannot access the file because it is being used by another process。
实操建议：
- 用循环 + 指数退避重试：首次等待 10ms，失败后等 20ms、40ms… 最多 5 次，超时则跳过该次事件（说明文件写入异常或被锁定太久）
- 不要用
File.Exists做前置判断——它和后续打开之间存在竞态窗口；直接尝试打开，捕获IOException和UnauthorizedAccessException - 对文本类文件，优先用
File.ReadAllText(path, Encoding.UTF8)而非流式读取，避免因编码探测失败导致乱码（尤其无 BOM 的 UTF-8 文件） - 若需校验文件完整性（如分发前比对哈希），务必在重试稳定打开后计算，而不是监听完立刻算——否则可能读到截断或未刷盘的内容
跨网络路径或 OneDrive/SharePoint 同步文件夹能用吗
不能。FileSystemWatcher 在 UNC 路径（\server\share）上行为不可靠，在云同步文件夹（OneDrive、Google Drive、iCloud）里基本不触发事件——因为这些服务通过虚拟文件系统（VFS）或客户端代理实现同步，绕过了 Windows 原生文件通知链。
实操建议：
- 监控本地路径，再由业务逻辑判断是否属于同步目录（例如检查
Path.GetFullPath(path)是否以%USERPROFILE%\OneDrive开头），如果是，降级为定时轮询（Directory.GetFiles+LastWriteTimeUtc对比） - 对 SMB 共享，确保客户端启用了“SMB 服务器消息块通知”（Server Message Block change notifications），但即便如此，延迟仍可能达数秒，且 Windows Server 版本差异大
- 绝对不要在
FileSystemWatcher里做跨网络 I/O（如上传、HTTP 请求）——网络抖动会导致事件队列积压、线程池饥饿，最终整个监控挂死
如何避免重复分发同一文件
一个文件被编辑三次，FileSystemWatcher 可能发出 5 个 Changed 事件（编辑器先清空再写入、临时备份文件、最后改名覆盖），但你的分发逻辑只需处理最终版本一次。
实操建议：
- 用文件完整路径 +
FileInfo.Length+FileInfo.LastWriteTimeUtc三元组做内存去重（ConcurrentDictionary<string, (long size, DateTime mtime)>），10 秒内相同三元组只处理第一次 - 对重命名场景（
Rename事件），记录旧名 → 新名映射，并在新名触发时主动清除旧名缓存，防止 rename + modify 组合造成重复 - 如果分发目标是消息队列（如 RabbitMQ、Kafka），把文件路径和 mtime 打包成幂等消息（加
message-id），由下游消费者负责去重，别把逻辑全堆在监控端 - 切忌用文件名（不含路径）做 key——同名文件在不同目录是合法且常见的情况
最麻烦的其实是“原子写入”模式：某些程序（如 VS Code、Git）写文件时先写 file.tmp，再 Move 覆盖原文件。这时候你既会收到 Created（tmp 文件），又会收到 Rename（覆盖动作），还可能收到原文件的 Deleted。处理链必须能识别这种模式，否则分发到一半发现文件被删就懵了。
