FileSystemWatcher短时间内多次触发Changed事件是因操作系统底层通知机制对单次逻辑操作（如保存文件）会发出多个事件，如Created、Changed、Renamed等；常见诱因包括编辑器自动保存、IDE编译、Git钩子等；推荐用Timer去抖或Channel+BackgroundService实现可靠事件流处理。
FileSystemWatcher为什么会在短时间内触发多次Changed事件
因为操作系统对文件系统的底层通知机制（如Windows的ReadDirectoryChangesW）本身就会为一次逻辑操作发出多个底层事件——比如保存一个文本文件，可能依次触发Created、Changed（写入）、Changed（属性更新）、Renamed（临时文件替换），甚至同一类事件（如Changed）被拆成多次调用。这不是C#的bug，而是FSW忠实地转播了系统信号。
常见诱因包括：编辑器自动保存、IDE编译输出、Git钩子写入、.NET热重载、防病毒软件扫描等。你看到的“多次触发”，往往对应真实发生的多次WriteFile或SetFileAttributes系统调用。
用Timer做简单去抖（Debounce）是最直接的方案
核心思路：不立即处理事件，而是启动一个短时定时器（比如300ms），每次收到新事件就重置它；只有定时器自然到期时才真正执行业务逻辑。这能有效合并连续写入、保存、覆盖等行为。
-
System.Timers.Timer比System.Threading.Timer更易管理生命周期，且支持AutoReset = false - 务必在
Timer.Elapsed中检查Enable = true，避免多线程竞争导致重复执行 - 把待处理的
FileSystemEventArgs缓存到字段或ConcurrentQueue，注意线程安全——FSW事件在后台线程触发 - 示例关键片段：
private readonly Timer _debounceTimer = new(300); private FileSystemEventArgs _lastEvent; public void OnChanged(object sender, FileSystemEventArgs e) { _lastEvent = e; _debounceTimer.Stop(); _debounceTimer.Start(); } private void OnTimerElapsed(object sender, ElapsedEventArgs e) { if (_debounceTimer.Enabled) return; // 防止竞态 _debounceTimer.Stop(); ProcessFileChange(_lastEvent); // 你的实际处理逻辑 }
区分事件类型和路径再合并，避免误吞关键变更
盲目合并所有Changed事件会丢失语义——比如Changed（内容）和Changed（LastWriteTime）应区别对待，而Created与后续Changed通常属于同一操作链，但Deleted必须立刻响应，不能等去抖。
- 优先合并同路径、同
ChangeType == WatcherChangeTypes.Changed的事件 - 对
WatcherChangeTypes.Created可设更短去抖窗口（100ms），确认不是临时文件残留 - 跳过对
.tmp、~$、.swp等临时文件后缀的监听，从源头减少干扰 - 设置
FileSystemWatcher.IncludeSubdirectories = false，除非真需要递归监控——子目录事件极易放大抖动
用Channel+BackgroundService实现高可靠事件流（.NET 6+）
当业务复杂、需顺序处理、或要求事件不丢失时，基于Channel构建异步管道比Timer更可控。它天然支持背压、取消和有序消费。
- 在
OnChanged里只做await _channel.Writer.WriteAsync(e, cancellationToken)，零阻塞 - 后台服务从
_channel.Reader.ReadAllAsync()拉取事件，内部按需去抖、分组、过滤 - 注意
Channel.CreateBounded要设合理容量（如100），防止突发事件撑爆内存 - 务必在
Dispose中调用_channel.Writer.Complete()，否则Reader会永远挂起
这种模式下，“合并”不再是硬性延迟，而是流式处理中的一个阶段：接收 → 缓存最近N秒事件 → 按路径/类型聚合 → 提交最终结果。真正的难点不在合并逻辑本身，而在如何定义“同一变更”的边界——比如编辑器保存一个.cs文件，究竟是算1次变更，还是应该等待编译完成后的.dll输出才算完整闭环？这取决于你的使用场景，没有银弹。
