filesystemwatcher 丢事件或重复触发的根本原因是其底层依赖的 readdirectorychangesw 使用固定大小内核缓冲区（默认8kb），溢出即丢弃且不报错；重命名等操作被拆分为多个底层事件导致应用层误判。
FileSystemWatcher 为什么总是丢事件或重复触发
根本原因是 FileSystemWatcher 底层依赖 Windows API 的 ReadDirectoryChangesW，它用固定大小的内核缓冲区（默认 8KB）暂存文件系统通知。缓冲区溢出时，事件直接丢弃，且不报错；而重命名、移动等操作可能被拆成多个底层事件（如先删除再新建），导致应用层看到重复或错乱的 Created/Renamed。
如何避免缓冲区溢出导致的事件丢失
关键不是盲目调大 InternalBufferSize，而是结合业务节奏合理设置：
-
InternalBufferSize必须是 4096 的整数倍，建议从65536（64KB）起步，但不要超过 640KB（Windows 限制） - 高频写入场景下，必须监听
Error事件并检查EventArgs.Error是否为ERROR_NOTIFY_ENUM_DIR（即缓冲区已满） - 一旦捕获该错误，应立即记录告警，并考虑临时降级：比如暂停非关键监听、触发一次全量扫描补漏
- 避免在事件回调中做耗时操作（如 IO、网络请求），否则会阻塞后续事件分发线程，间接加剧丢事件风险
如何识别和合并重复的 Renamed 或 Created 事件
Rename 是最易误判的操作——例如 VS 编译器保存文件时，常先写临时文件再原子替换，FileSystemWatcher 会报告 Created + Deleted + Renamed 一连串事件。解决思路是加时间窗口+路径指纹去重：
- 用
ConcurrentDictionary<string datetime></string>缓存最近 5 秒内所有事件的FullPath及时间戳 - 在
Renamed回调里，检查e.OldFullPath和e.FullPath是否都在缓存中且时间差 - 对
Created事件，可配合File.GetLastWriteTimeUtc()检查是否与上一个同名文件的修改时间接近（防编辑器临时文件干扰）
替代方案：什么时候该放弃 FileSystemWatcher
当业务要求强一致性（如备份工具、审计日志），FileSystemWatcher 不适合单独使用：
- 短生命周期文件（如日志轮转生成的
.tmp文件）极易被漏掉 - 跨卷移动、硬链接、符号链接等操作无法被可靠捕获
- 推荐组合策略：用
FileSystemWatcher做“快响应”提示，再辅以定时扫描（如每 30 秒查Directory.EnumerateFiles()+FileInfo.LastWriteTimeUtc）做最终校验 - 更重场景可考虑 Windows 的
USN Journal（需管理员权限 + 驱动级访问），但开发成本陡增，多数应用没必要
真正难处理的永远不是“怎么监听”，而是“怎么确认监听到了全部”。缓冲区溢出无声无息，重复事件又常发生在调试环境里不复现——上线前务必用高并发写入脚本压测，别只靠单步调试信誓旦旦。
